domain to all of its external peers (BRs in adjacent domains), via
BGP or IDRP. In BGP and IDRP, a BR must advertise a route to
destinations within its domain to all of its external peers (BRs in
adjacent domains).
If a BR receives a route to an adjacent domain from a BR in that
domain and selects that route as part of its BGP or IDRP Decision
Process, then it must propagate this route (via BGP or IDRP) to all
other BRs within its domain. A BR may also propagate such a route if
it depicts an autonomous system other than the adjacent domain.
Since AS numbers are encoded as network numbers in network 128.0.0.0,
it is possible to also advertise a route to a domain in BGP or IDRP.
9. SDRP MTU Discovery
To participate in Path MTU Discovery ([6]) a router may maintain
information about the maximum length of the payload packet that can
be carried without fragmentation along a particular SDRP route.
SDRP provides two complimentary techniques to support MTU Discovery.
The first one is passive and is based on the receipt of the ICMP
Destination Unreachable messages (as described in Section 7.2). By
combining information provided in the ICMP message with local
information about the SDRP route the local system can determine the
length of a payload packet that would require fragmentation.
The second one is active and employs the Probe Indicator bit. If an
SDRP data packet that carries the Probe Indicator bit in the SDRP
header and Don't Fragment flag in the delivery header triggers the
last router on the SDRP route to return an SDRP Control packet (with
the Notification Code "Probe Completed"), then the information
carried in the payload header of the control packet can be used to
determine the length of the payload packet that went through the SDRP
route without fragmentation.
10. Acknowledgments
The authors would like to thank Scott Bradner (Harvard University),
Noel Chiappa (Consultant), Joel Halpern (Newbridge Networks),
Christian Huitema (INRIA), and Curtis Villamizar (ANS) for their
comments on various aspects of this document.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Deborah Estrin
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, Ca 90292-6695.
Phone: +1 310 822 1511 x 253
EMail: estrin@isi.edu
Tony Li
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, CA 94025
Phone: +1 415 526 8186
EMail: tli@cisco.com
Yakov Rekhter
Cisco systems
170 West Tasman Drive
San Jose, CA, USA
Phone: +1 914 528 0090
Fax: +1 408 526-4952
EMail: yakov@cisco.com
Kannan Varadhan
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, Ca 90292-6695.
Phone: +1 310 822 1511 x 402
EMail: kannan@isi.edu
Daniel Zappala
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, Ca 90292-6695.
Phone: +1 310 822 1511 x 352
EMail: daniel@isi.edu
References
[1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3), RFC1267, October 1991.
[2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
Protocol in the Internet", RFC1268, October 1991.
[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC1654, July 1994.
[4] Hares, S., "IDRP for IP", IDR Working Group, 1994.
Work in Progress.
[5] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC791, September 1981.
[6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC1191,
November 1990.
[7] Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2,
RFC1700, October 1994.