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:
- All hosts are capable of sending and receiving multicast packets
if multicast destinations are to be supported.
- 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 224.0.0.14, 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.
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.
- 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.
- 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
|