Connected: An Internet Encyclopedia
APPENDIX C. UDP Encapsulation

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2205
Prev: APPENDIX B. Error Codes and Values
Next: APPENDIX D. Glossary

APPENDIX C. UDP Encapsulation

APPENDIX C. UDP Encapsulation

An RSVP implementation will generally require the ability to perform "raw" network I/O, i.e., to send and receive IP datagrams using protocol 46. However, some important classes of host systems may not support raw network I/O. To use RSVP, such hosts must encapsulate RSVP messages in UDP.

The basic UDP encapsulation scheme makes two assumptions:

  1. All hosts are capable of sending and receiving multicast packets if multicast destinations are to be supported.

  2. The first/last-hop routers are RSVP-capable.

A method of relaxing the second assumption is given later.

Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a host that can do raw network I/O. The UDP encapsulation scheme must allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu hosts, and routers.

Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast addresses learned from the path or reservation state in the node. If the node keeps track of which previous hops and which interfaces need UDP encapsulation, these messages can be sent using UDP encapsulation when necessary. On the other hand, Path and PathTear messages are sent to the destination address for the session, which may be unicast or multicast.

The tables in Figures 13 and 14 show the basic rules for UDP encapsulation of Path and PathTear messages, for unicast DestAddress and multicast DestAddress, respectively. The other message types, which are sent unicast, should follow the unicast rules in Figure 13. Under the `RSVP Send' columns in these figures, the notation is `mode(destaddr, destport)'; destport is omitted for raw packets. The `Receive' columns show the group that is joined and, where relevant, the UDP Listen port.

It is useful to define two flavors of UDP encapsulation, one to be sent by Hu and the other to be sent by Hr and R, to avoid double processing by the recipient. In practice, these two flavors are distinguished by differing UDP port numbers Pu and Pu'.

The following symbols are used in the tables.

The following notes apply to these figures:

   UNICAST DESTINATION D:

                   RSVP               RSVP
   Node            Send               Receive
   ___       _____________          _______________
   Hu         UDP(D/Ra,Pu)          UDP(D,Pu)
                 [Note 1]       and UDP(D,Pu')
                                       [Note 2]

   Hr         Raw(D)                Raw()
               and if (UDP)     and UDP(D, Pu)
               then UDP(D,Pu')         [Note 2]
                                    (Ignore Pu')

   R (Interface a):
              Raw(D)                Raw()
               and if (UDP)     and UDP(Ra, Pu)
               then UDP(D,Pu')      (Ignore Pu')

   Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages

   MULTICAST DESTINATION D:

                  RSVP                    RSVP
   Node           Send                    Receive
   ___           _____________        _________________
   Hu             UDP(G*,Pu)              UDP(D,Pu')
                                              [Note 3]
                                      and UDP(G*,Pu)

   Hr             Raw(D,Tr)               Raw()
                   and if (UDP)       and UDP(G*,Pu)
                     then UDP(D,Pu')     (Ignore Pu')

   R (Interface a):
                  Raw(D,Tr)               Raw()
                   and if (UDP)       and UDP(G*,Pu)
                     then UDP(D,Pu')     (Ignore Pu')

      Figure 14: UDP Encapsulation Rules for Multicast Path Messages

A router may determine if its interface X needs UDP encapsulation by listening for UDP-encapsulated Path messages that were sent to either G* (multicast D) or to the address of interface X (unicast D). There is one failure mode for this scheme: if no host on the connected network acts as an RSVP sender, there will be no Path messages to trigger UDP encapsulation. In this (unlikely) case, it will be necessary to explicitly configure UDP encapsulation on the local network interface of the router.

When a UDP-encapsulated packet is received, the IP TTL is not available to the application on most systems. The RSVP process that receives a UDP-encapsulated Path or PathTear message should therefore use the Send_TTL field of the RSVP common header as the effective receive TTL. This may be overridden by manual configuration.

We have assumed that the first-hop RSVP-capable router R is on the directly-connected network. There are several possible approaches if this is not the case.

  1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu) with TTL=Ta

    Here Ta must be the TTL to exactly reach R. If Ta is too small, the Path message will not reach R. If Ta is too large, R and succeeding routers may forward the UDP packet until its hop count expires. This will turn on UDP encapsulation between routers within the Internet, perhaps causing bogus UDP traffic. The host Hu must be explicitly configured with Ra and Ta.

  2. A particular host on the LAN connected to Hu could be designated as an "RSVP relay host". A relay host would listen on (G*,Pu) and forward any Path messages directly to R, although it would not be in the data path. The relay host would have to be configured with Ra and Ta.


Next: APPENDIX D. Glossary

Connected: An Internet Encyclopedia
APPENDIX C. UDP Encapsulation