Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Connection Oriented Networks - Perros H.G

Perros H.G Connection Oriented Networks - John Wiley & Sons, 2005. - 359 p.
ISBN 0-470-02163-2
Download (direct link): connectionorientednetworks2005.pdf
Previous << 1 .. 97 98 99 100 101 102 < 103 > 104 105 106 107 108 109 .. 181 >> Next

INTEGRITY: Carries cryptographic data to authenticate the originating node to verify the contents of this RSVP message.
SCOPE: Carries an explicit list of sender hosts towards the information in the message is to be forwarded. It can appear in a Resv, ResvErr, or ResvTear message.
RESV CONFIRM: Carries the IP address of a receiver that requested a confirmation. It can appear in a Resv or ResvConf message.
Below, we describe the Path and Resv messages.
172
LABEL DISTRIBUTION PROTOCOLS
7.3.4 The Path Message
The Path message consists of the common header shown in Figure 7.20 followed by the objects:
INTEGRITY (optional)
SESSION
RSVP_HOP
TIME_VALUES
POLICYDATA objects (optional)
A sender descriptor consisting of SENDERTEMPLATE and the SENDERTSPEC
ADSPEC (optional)
Each sender host sends a Path message for each data flow it wishes to transmit. The Path message is forwarded from router to router using the next hop information in the routing table until it reaches the receiver. Each router along the path captures and processes the Path message. The router creates a path state for the pair {sender, receiver} defined in the SENDER TEMPLATE and SESSION objects of the Path message. Any POLICY DATA, SENDER TSPEC, and ADSPEC objects are also saved in the path state. If an error is encountered a PathErr message is sent back to the originator of the Path message.
7.3.5 The Resv Message
When a receiver receives a Path message, it issues a Resv message which is sent back to the sender along the reverse path traveled by the Path message. Recall that the data packets follow the same path traveled by the Path message. The Resv message is a request to each node along the path to reserve resources for the data flow. It consists of the common header shown in Figure 7.20 followed by the objects:
INTEGRITY (optional)
SESSION
RSVP_HOP
TIME_VALUES
RESVCONFIRM (optional)
SCOPE (optional)
POLICY DATA objects (optional)
STYLE
A flow descriptor list
The RSVP HOP contains the NHOP (i.e., the IP address of the router that sent the Resv message). The presence of the RESV CONFIRM object in the Resv message is a signal to the router to send a ResvConf message to the receiver to confirm the reservation. The RESV CONFIRM carries the IP address of the receiver.
The flow descriptor list is style dependent. For the wildcard-filter (WF) style the flow descriptor list consists of the FLOWSPEC object. For the fixed-filter (FF) and shared explicit (SE) styles, it consists of the objects FLOWSPEC and FILTER SPEC.
As mentioned above, RSVP is not aware of the content of the RSVP objects that contain the traffic information used by the routers to reserve resources. This was done
THE RESOURCE RESERVATION PROTOCOL - TRAFFIC ENGINEERING
173
purposefully so that the applicability of RSVP is not restricted to the intserv architecture. Below, we describe the contents of the SENDERSPEC and ELOWSPEC objects as they have been defined for the intserv architecture.
SENDERTSPEC and FLOWSPEC contents for intserv
The SENDER TSPEC contains the traffic parameters: token bucket rate, token bucket size, peak data rate, minimum policed unit (i.e., size of smallest allowable packet), and maximum policed unit (i.e., size of maximum allowable packet).
The contents of the FLOWSPEC depend on whether the controlled-load service or the guaranteed service is requested. When requesting the controlled-load service, the FLOWSPEC consists of the receiver TSPec which contains values for the parameters: token bucket rate, token bucket size, peak data rate minimum policed unit, and maximum policed unit. These parameters are used to calculate the resource reservation in a router.
When requesting the guaranteed service, the FLOWSPEC consists of the receiver TSpec and the RSpec which carries the parameters rate and slack time. These two parameters are used to define the desired bandwidth and delay guarantee.
7.4 THE RESOURCE RESERVATION PROTOCOL - TRAFFIC ENGINEERING (RSVP-TE)
The resource reservation protocol - traffic engineering (RSVP-TE) is an extension of the resource reservation protocol (RSVP), described above. RSVP-TE can be used in MPLS to set up LSPs using either the next hop information in the routing table or an explicit route.
In keeping with the terminology used in RSVP-TE (which in fact is the same as in RSVP) we will use the terms node, sender, and receiver to indicate an LSR, an ingress LSR, and an egress LSR, respectively. Recall that, in RSVP, a session is a data flow with a particular IP destination address and protocol id. In RSVP-TE, a session is an LSP.
RSVP-TE uses downstream-on-demand label allocation to set up an LSP. This is implemented using the Path and Resv messages which have been augmented with new objects. An LSP can be set up using the next hop information in the routing table. Also, RSVP-TE can set up explicitly routed LSPs. This is done by using a new object - the EXPLICITROUTE - to encapsulate the hops that make up the explicit path. Each hop in the path can be an individual node or an abstract node. An abstract node is a group of nodes whose internal topology is opaque to the sender. Strict or loose routing through an abstract node is permitted.
Previous << 1 .. 97 98 99 100 101 102 < 103 > 104 105 106 107 108 109 .. 181 >> Next