blank.gif (43 bytes)

Church Of The
Swimming Elephant

APPENDIX C. UDP Encapsulation 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.

  • D is the DestAddress for the particular session.

  • G* is a well-known group address of the form, i.e., a group that is limited to the local connected network.

  • Pu and Pu' are two well-known UDP ports for UDP encapsulation of RSVP, with values 1698 and 1699.

  • Ra is the IP address of the router interface `a'.

  • Router interface `a' is on the local network connected to Hu and Hr.

The following notes apply to these figures:

    [Note 1] Hu sends a unicast Path message either to the destination address D, if D is local, or to the address Ra of the first-hop router. Ra is presumably known to the host.

    [Note 2] Here D is the address of the local interface through which the message arrived.

    [Note 3] This assumes that the application has joined the group 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


                  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


Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

Have you gone to church today?
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609