Add Book to My BookshelfPurchase This Book Online

Chapter 10 - Resource Reservation Protocol

Cisco Multicast Routing & Switching
William R. Parkhurst
  Copyright © 1999 The McGraw-Hill Companies

Reservation Style Summary
The three RSVP styles and the actions a router will take when merging requests are summarized in Figures 10-7 through 10-10.
Figure 10-7: The merging of WF style RSVP requests. The size of the resource allocated is equal to the largest, regardless of the senders.
Figure 10-8: The merging of FF style RSVP requests for distinct sources is shown. For each distinct source allocated, the requested resource is shown also. For a common source allocated, the largest of the resource is requested. The allocated bandwidth equals 300.
Figure 10-9: The merging of FF style RSVP requests for a common source. For a common source, allocate the largest of the resources requested. The allocated bandwidth equals 100.
Figure 10-10: The merging of SE style RSVP requests. Merge all sources and allocate the largest of the requested resource for all specified sources. The total bandwidth allocated equals 300.
RSVP Protocol Messages
When discussing RSVP messages we need to agree on the definition of terms. Figure 10-11 illustrates some fundamental terms used in discussing RSVP messages. The incoming and outgoing interfaces, as well as the next and previous hops, are from the point of view of the data flow. RSVP utilizes two types of messages for resource reservation. The first message is a reservation request (RESV) message that is sent from receivers to senders. The RESV messages will traverse the network from the receiver to the sources in the messages along the RPF interfaces as discussed in previous chapters. A reservation state will be established in each router along the path.
Figure 10-11: RSVP terminology
Each source that implements RSVP will transmit Path messages along the route that the data will follow. At each node along the path, the path state is stored. The path state is used to route the reservation messages. A fundamental component of the path state is the IP address of the previous hop. In Figure 10-11, the previous hop for router B is router A, as shown. The path message contains other required components and possibly optional components for the establishment of the path state. The two required components are the Sender Template and the Sender Tspec. Sender Template contains a description of the structure of the packets that the source sends in the form of a filter spec. This implies that the sender template will contain the IP address of the source and possibly the UDP port the source is using. The Sender Tspec defines the characteristics of the traffic the source will originate in order to prevent over-reservation. An optional component of a path message is the Adspec. An Adspec carries One Pass With Advertising (OPWA) information. As the Path message travels towards the receiver, information is collected at each node so the receiver is able to predict the end-to-end service. This information is referred to as an advertisement, hence, the name Adspec. When the path message arrives at a node, the Adspec is passed to the local traffic control module. The local traffic control module updates the Adspec which is sent in a path message to the next downstream node.
The state that is established along the path from the source to receiver is a dynamic, or soft, state. It is refreshed by periodic path and reservation messages. If there are any changes in the reservation request, they are contained in the request updating the soft state in the routers. The state maintains a cleanup timeout timer whose expiration causes the state to be deleted. A state may also be deleted by the reception of a teardown message. Teardown messages will remove reservation of path state upon reception of the message. Two types of states are established — path and reservation — so two teardown messages — ResvTear and PathTear —  are also established.
RSVP uses two messages to report errors. For path errors, the PathErr message is used. PathErr messages are sent upstream toward the source that was the cause of the error. Intermediate nodes the PathErr message crosses won’t have its path state modified. For reservation errors, the ResvErr message is used. When a reservation request is denied by the admission control module, existing reservations are unaffected and the error is reported to all affected receivers. ResvErr messages create a new state in the nodes the error message traverses. This state is called the blockade state and prevents the flowspec that caused the error to be omitted from the flowspec merging process.
RSVP confirmation messages (ResvConf) are used to signal the requesting receiver that the reservation was successful. When a reservation request reaches a merge point and the request is smaller than or equal to an existing reservation, the reservation has succeeded. At this point, if the receiver requested a confirmation, then a ResvConf message will be sent back to the receiver.
There may be situations where RSVP reservation and path messages may be routed through routers that are not RSVP capable (see Figure 10-12).
Figure 10-12: A non-RSVP router in the path between the receiver and source
A path message from the source will be forwarded towards the destination by both the RSVP capable and non-RSVP capable routers and allow RSVP to operate correctly. Problems may arise because there is no knowledge about the non-RSVP router and whether or not it can handle the reservations that were setup on the RSVP capable routers. In this case RSVP will propagate a non-RSVP flag to the local traffic control module and will be forwarded using Adspecs. Non-RSVP capable routers can cause an RSVP message to arrive at the wrong node or the wrong interface on the correct node. A Logical Interface Handle (LIH) is used to handle the case of the wrong interface on the right router. The previous hop information in the path message will contain the IP address of the previous hop and a LIH identifying the interface.
RSVP Message Formats
Every RSVP message begins with a common header (see Figure 10-13).
Figure 10-13: RSVP message header format
Version
Four-bit version number. Current version is 1.
Flags
Four-bit number. Not defined.
Msg type
Eight-bit number.
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf
RSVP Checksum
16-bit ones complement sum of the RSVP message.
Send_TTL
Eight-bit original TTL value of the message.
RSVP Length
16-bit total length of the RSVP message.
Each RSVP message has an object field that follows the common header. The object field has a minimum size of 32-bits, as shown in Figure 10-14.
Figure 10-14: RSVP Object format
Length
Sixteen-bit length in bytes of the object. The length must be a multiple of four and the minimum length is four bytes.
C-Type
Identifies the address family. One is for IPv4 and 2 is for IPv6.
Class-Num
Type of object contained in the message. The Class-Num identifiers and their corresponding packet formats and descriptions are contained in Figures 10-15 — 10-16.
Figure 10-15: IPv4 UDP Session Object; Class-Num = 1 C-Type = 1
Figure 10-16: IPv6 UDP Session object; Class-Num = 1 C-Type = 2
Class-Num identifies one of the following objects.
NULL
NULL objects are ignored and can be anywhere in the message. The object length is a multiple of four bytes.
SESSION
A session object is required in every RSVP message. This object will contain the IP address of the destination, the IP protocol ID and the destination port.
RSVP_HOP
Contains the IP address of the RSVP node that sent the message along with the Logical Interface Handle (LIH). For downstream messages, the object is referred to as a previous hop (PHOP) object and for next hop or upstream messages it is referred to as a next hop (NHOP) object.
TIME_VALUES
Every Path and RESV message will contain a TIME_VALUES object that contains the refresh period. This object is required in every Resv and Path message.
STYLE
Contains the reservation style, WF, FF, or SE, and style specific information not contained in FLOWSPEC or FILTER_SPEC objects.
FLOWSPEC
Contains the desired QoS. Used in the RESV message.
FILTER_SPEC
Used to identify the data packets in a session that should receive the requested QoS. Used in the RESV message.
SENDER_TEMPLATE
Contains the sender’s IP address and is required in the Path message.
ADSPEC
Contains OPWA information and is used in the PATH message.
ERROR_SPEC
Identifies the error that is being returned in a PathErr or ResvErr message. Also used as a confirmation in a ResvConf message.
POLICY_DATA
Not currently specified.
INTEGRITY
Contains cryptographic information to authenticate the originating node and to verify the message.
SCOPE
Contains a list of senders to which the message is forwarded.
RESV_CONFIRM
Contains the IP address of the receiver that requested the confirmation.
The Session class object, shown in Figures 10-15 and 10-16, specifies the session for the objects that follow in the message. The destination address, in conjunction with the UDP destination port field, identifies the session. The destination address can be either a multicast or unicast address.
The RSVP_HOP message (see Figures 10-17 and 10-18) contains the IP address and Logical Interface Handle (LIH) of the RSVP node that forwarded the message.
Figure 10-17: IPv4 RSVP_HOP object; Class-Num = 3 C-Type = 1
Figure 10-18: IPv6 RSVP_HOP object; Class-Num = 3 C-Type = 2
The TIME_VALUE object (see Figure 10-19) contains the refresh period in milliseconds.
Figure 10-19: TIME_VALUES object; Class-Num = 5 C-Type = 1
The ERROR_SPEC object contains the IP address of the node where the error was detected (see Figure 10-21). The flags field has the values listed on the following page.
Figure 10-20: IPv4 ERROR_SPEC object; Class-Num = 6 C-Type = 1
Figure 10-21: IPv6 ERROR_SPEC object; Class-Num = 6 C-Type = 2
0x01 (InPlace)
If this bit is set then a reservation is in place on the node where the error occurred. Only used in a ResvErr message.
0x02 (NotGuilty)
If set then indicates that the FLOWSPEC that failed was greater than the FLOWSPEC that was requested by the receiver.
Error code  0
Type
Confirmation.
Description
Used in the ERROR_SPEC object in a ResvConf message.
Error Value
0
Error Code  1
Type
Admission Control Failure.
Description
The reservation request failed due to resource(s) not available.
Error Value
The 16 bits of the error value are defined as follows:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
  s   s   u    r    c    c  c c  c c c c c c c c
ss = 00
Error Code  2
Type
Policy control failure.
Description
A reservation or path message failed for administrative reasons.
Error Value
Undefined.
Error Code  3
Type
No path state for the session and the resv message cannot be forwarded.
Error value
Undefined.
Error Code  4
Type
No sender information for the Resv message.
Description
A path state exists for the session but the state does not contain a flow descriptor that matches the sender in the Resv message.
Error value
Undefined.
Error Code  5
Type
Conflicting reservation style.
Description
The requested reservation style conflicts with the existing style.
Error Value
Lower order 16-bits of the option vector of the existing style.
Error Code  6
Type
Unknown reservation style.
Error Code  7
Type
Conflicting destination ports.
Description
Sessions for the same destination address and protocol and appeared with both zero and non-zero destination port fields.
Error Value
Undefined.
Error Code  8
Type
Conflicting sender ports.
Description
The sender port is both zero and non-zero in path messages for the same session.
Error Code  9,10,11
Type
Reserved.
Error Code  12
Type
Service preempted.
Description
The service requested by the STYLE object and the flow descriptor has been administratively preempted.
Error value
Error Code  13
Type
Unknown object class.
Error Value
Contains the Class-Num and C-type of the unknown object.
Error Code  14
Type
Unknown object C-type.
Error Value
Contains the Class-Num and C-type of the unknown object.
Error Code  15, 16, 17, 18, 19, 20
Type
Reserved.
Error Code  21
Type
Traffic control error.
Description
Traffic control call failed due to the format or contents of the request.
Error Code  22
Type
Traffic control system error.
Description
A system error was detected and reported by the traffic control modules.
Error Value
System specific.
Error Code  23
Type
RSVP system error.
Description
Every RSVP message is rebuilt at every hop and an error in a node could cause a malformed message.
Error Value
Implementation dependent.
The SCOPE class object is a list of IP addresses used for routing messages with wildcard scope without loops (see Figures 10-22 and 10-23). The addresses must be listed in ascending order.
Figure 10-22: IPv4 SCOPE List object; Class-Num = 7 C-Type = 1
Figure 10-23: IPv6 SCOPE List object; Class-Num = 7 C-Type = 2
The STYLE object identifies the reservation type (see Figure 10-24) and the flags field is not defined. The 24-bit option vector (see Figure 10-25) identifies the style.
Figure 10-24: STYLE object; Class-Num = 8 C-Type = 1
0x10001-WF
0x01010-FF
0x10010-SE
Figure 10-25: Option Vector bit definitions
The FILTER_SPEC object contains the IP source address for the sender (see Figures 10-26, 10-27, and 10-28). The source port field contains the UDP/TCP port for the sender or 0 to indicate “none.”
Figure 10-26: IPv4 FILTER_SPEC object; Class-Num = 10 C-Type = 1
Figure 10-27: IPv6 FILTER_SPEC object; Class-Num = 10 C-Type = 2
Figure 10-28: IPv6 FILTER_SPEC object; Class-Num = 10 C-Type = 3
The SENDER_TEMPLATE object contains the IP source address for the sender (see Figures 10-29, 10-30, and 10-31). The source port field contains the UDP/TCP port for the sender or 0 to indicate “none.”
Figure 10-29: IPv4 SENDER_TEMPLATE object; Class-Num = 11 C-Type = 1
Figure 10-30: IPv6 SENDER_TEMPLATE object; Class-Num = 11 C-Type = 2
Figure 10-31: IPv6 SENDER_TEMPLATE object; Class-Num = 11 C-Type = 3

 


 
Books24x7.com, Inc © 2000 –  Feedback