< draft-ietf-mpls-ldp-mtu-extensions-02.txt   draft-ietf-mpls-ldp-mtu-extensions-03.txt >
Network Working Group B. Black Network Working Group B. Black
Internet Draft Layer8 Networks Internet Draft Layer8 Networks
Updates: 3036 K. Kompella Category: Experimental K. Kompella
Category: Standards Track Juniper Networks Juniper Networks
Expires: April 2004 October 2003 Expires: October 2004 April 2004
Maximum Transmission Unit Signalling Extensions Maximum Transmission Unit Signalling Extensions
for the Label Distribution Protocol for the Label Distribution Protocol
draft-ietf-mpls-ldp-mtu-extensions-02.txt draft-ietf-mpls-ldp-mtu-extensions-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 35
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU)
discovery requires that IP routers have knowledge of the MTU for each discovery requires that IP routers have knowledge of the MTU for each
link to which they are connected. As currently specified, the Label link to which they are connected. As currently specified, the Label
Distribution Protocol (LDP) does not have the ability to signal the Distribution Protocol (LDP) does not have the ability to signal the
MTU for a Label Switched Path (LSP) to the ingress Label Switching MTU for a Label Switched Path (LSP) to the ingress Label Switching
Router (LSR). In the absence of this functionality, the MTU for each Router (LSR). In the absence of this functionality, the MTU for each
LSP must be statically configured by network operators or by LSP must be statically configured by network operators or by
equivalent, off-line mechanisms. equivalent, off-line mechanisms.
This document specifies extensions to LDP in support of LSP MTU This document specifies experimental extensions to LDP in support of
discovery. LSP MTU discovery.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
Changes from last version Changes from last version
[Note to RFC Editor: please remove this section before publishing.] [Note to RFC Editor: please remove this section before publishing.]
Incorporated suggestions received on the MPLS WG mailing list, mostly - changed category to Experimental
clarifications and editorial nits. - incorporated suggestions from WG chairs and IESG
Expanded examples. Made slight formatting changes.
Updated references.
1. Introduction 1. Introduction
As currently specified in [2], the LDP protocol for MPLS does not As currently specified in [2], the LDP protocol for MPLS does not
support signalling of the MTU for LSPs to ingress LSRs. This support signalling of the MTU for LSPs to ingress LSRs. This
functionality is essential to the proper functioning of RFC 1191 path functionality is essential to the proper functioning of RFC 1191 path
MTU detection [3]. Without knowledge of the MTU for an LSP, edge MTU detection [3]. Without knowledge of the MTU for an LSP, edge
LSRs may transmit packets along that LSP which are, according to [4], LSRs may transmit packets along that LSP which are, according to [4],
too big. Such packets may be silently discarded by LSRs along the too big. Such packets may be silently discarded by LSRs along the
LSP, effectively preventing communication between certain end hosts. LSP, effectively preventing communication between certain end hosts.
The solution proposed in this document enables automatic The solution proposed in this document enables automatic
determination of the MTU for an LSP with the addition of a TLV to determination of the MTU for an LSP with the addition of a Type-
carry MTU information for a FEC between adjacent LSRs in LDP Label Length-Value triplet (TLV) to carry MTU information for a Forwarding
Mapping messages. This information is sufficient for a set of LSRs Equivalence Class (FEC) between adjacent LSRs in LDP Label Mapping
along the path followed by an LSP to discover either the exact MTU messages. This information is sufficient for a set of LSRs along the
for that LSP, or an approximation which is no worse than could be path followed by an LSP to discover either the exact MTU for that
generated with local information on the ingress LSR. LSP, or an approximation which is no worse than could be generated
with local information on the ingress LSR.
2. MTU Signalling 2. MTU Signalling
The signalling procedure described in this document employs the The signalling procedure described in this document employs the
addition of a single TLV to LDP Label Mapping messages and a simple addition of a single TLV to LDP Label Mapping messages and a simple
algorithm for LSP MTU calculation. algorithm for LSP MTU calculation.
2.1. Definitions 2.1. Definitions
Link MTU: the MTU of a given link. This size includes the IP header Link MTU: the MTU of a given link. This size includes the IP header
skipping to change at page 8, line 11 skipping to change at page 8, line 11
If the payload for the LSP is not an IP packet, the LSR MUST forward If the payload for the LSP is not an IP packet, the LSR MUST forward
the packet if it fits (size <= LSP MTU), and SHOULD drop it if it the packet if it fits (size <= LSP MTU), and SHOULD drop it if it
doesn't fit. doesn't fit.
5. Protocol Interaction 5. Protocol Interaction
5.1. Interaction With LSRs Which Do Not Support MTU Signalling 5.1. Interaction With LSRs Which Do Not Support MTU Signalling
Changes in MTU for sections of an LSP may cause intermediate LSRs to Changes in MTU for sections of an LSP may cause intermediate LSRs to
generate unsolicited label Mapping messages to advertise the new MTU. generate unsolicited label Mapping messages to advertise the new MTU.
LSRs which do not support MTU signalling MUST accept these messages, LSRs which do not support MTU signalling will accept these messages,
but MAY ignore them (see Section 2.1). but will ignore them (see Section 2.4).
5.2. Interaction with CR-LDP and RSVP-TE 5.2. Interaction with CR-LDP and RSVP-TE
The MTU TLV can be used to discover the Path MTU of both LDP LSPs and The MTU TLV can be used to discover the Path MTU of both LDP LSPs and
CR-LDP LSPs. This proposal is not impacted in the presence of LSPs CR-LDP LSPs. This proposal is not impacted in the presence of LSPs
created using CR-LDP, as specified in [5]. created using CR-LDP, as specified in [5].
Note that LDP/CR-LDP LSPs may tunnel through other LSPs signalled Note that LDP/CR-LDP LSPs may tunnel through other LSPs signalled
using LDP, CR-LDP or RSVP-TE [6]; the mechanism suggested here using LDP, CR-LDP or RSVP-TE [6]; the mechanism suggested here
applies in all these cases, essentially by treating the tunnel LSPs applies in all these cases, essentially by treating the tunnel LSPs
skipping to change at page 8, line 40 skipping to change at page 8, line 40
[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. [2] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
Thomas, "LDP Specification", RFC 3036, January 2001 Thomas, "LDP Specification", RFC 3036, January 2001
[3] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, [3] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990 November 1990
[4] Rosen, E., Tappan, D., Federkow, G., Rekhter, Y., Farinacci, D., [4] Rosen, E., Tappan, D., Federkow, G., Rekhter, Y., Farinacci, D.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
January 2001 January 2001
[5] Jamoussi, B., Ed., "Constraint-Based LSP Setup Using LDP", RFC
3212, January 2002
[6] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. [6] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001 3209, December 2001
Informative References
[5] Jamoussi, B., Ed., "Constraint-Based LSP Setup Using LDP", RFC
3212, January 2002
Security Considerations Security Considerations
This mechanism does not introduce any new weaknesses in LDP. It is This mechanism does not introduce any new weaknesses in LDP. It is
possible to spoof TCP packets belonging to an LDP session to possible to spoof TCP packets belonging to an LDP session to
manipulate the LSP MTU, but LDP has mechanisms to thwart these types manipulate the LSP MTU, but LDP has mechanisms (see Section 5 of [2])
of attacks. to thwart these types of attacks.
IANA Considerations IANA Considerations
A new LDP TLV Type is defined in section 2.4. A Type has to be A new LDP TLV Type is defined in section 2.4. A Type has to be
allocated by IANA; a number from the range 0x0000 - 0x3DFF is allocated by IANA; a number from the range 0x0000 - 0x3DFF is
requested. requested.
Acknowledgments Acknowledgments
We would like to thank Andre Fredette for a number of detailed We would like to thank Andre Fredette for a number of detailed
skipping to change at page 10, line 29 skipping to change at page 10, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 12 change blocks. 
28 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/