draft-ietf-mpls-explicit-null-01.txt   draft-ietf-mpls-explicit-null-02.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: October 2004 Expiration Date: August 2005
Updates RFC 3032 Updates RFC 3032
April 2004 February 2005
Removing a Restriction on the use of MPLS Explicit NULL Removing a Restriction on the use of MPLS Explicit NULL
draft-ietf-mpls-explicit-null-01.txt draft-ietf-mpls-explicit-null-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 2, line 5 skipping to change at page 1, line 44
Abstract Abstract
The label stack encoding for MPLS (Multi-protocol Label Switching) The label stack encoding for MPLS (Multi-protocol Label Switching)
defines a reserved label value known as "IPv4 Explicit NULL" and a defines a reserved label value known as "IPv4 Explicit NULL" and a
reserved label value known as "IPv6 Explicit NULL". Previously, reserved label value known as "IPv6 Explicit NULL". Previously,
these labels were only legal when they occurred at the bottom of the these labels were only legal when they occurred at the bottom of the
MPLS label stack. This restriction is now removed, so that these MPLS label stack. This restriction is now removed, so that these
label values may legally occur anywhere in the stack. label values may legally occur anywhere in the stack.
This document updates RFC 3032.
Contents Contents
1 Introduction ......................................... 2 1 Introduction ......................................... 2
2 Detail of Change ..................................... 2 2 Detail of Change ..................................... 2
3 Reasons for Change ................................... 4 3 Reasons for Change ................................... 4
4 Security Considerations .............................. 5 4 Deployment Considerations ............................ 5
5 Acknowledgments ...................................... 5 5 Security Considerations .............................. 6
6 Normative References ................................. 6 6 Acknowledgments ...................................... 6
7 Informative References ............................... 6 7 Normative References ................................. 6
8 Author's Address ..................................... 6 8 Informative References ............................... 6
9 Intellectual Property Notice ......................... 6 9 Author's Address ..................................... 6
10 Copyright Notice ..................................... 7 10 Intellectual Property Statement ...................... 6
11 Full Copyright Statement ............................. 7
1. Introduction 1. Introduction
RFC 3032 defines a reserved label value known as "IPv4 Explicit NULL" RFC 3032 defines a reserved label value known as "IPv4 Explicit NULL"
and a reserved label value known as "IPv6 Explicit NULL". It states and a reserved label value known as "IPv6 Explicit NULL". It states
that these label values are only legal at the bottom of the MPLS that these label values are only legal at the bottom of the MPLS
label stack. However, no reason is given for this restriction. label stack. However, no reason is given for this restriction.
It has turned out that in practice there are some situations in which It has turned out that in practice there are some situations in which
it is useful to send MPLS packets which have Explicit NULL occur it is useful to send MPLS packets which have Explicit NULL occur
skipping to change at page 5, line 12 skipping to change at page 5, line 12
of the Explicit Null label stack entry, and the tunneled Diff-Serv of the Explicit Null label stack entry, and the tunneled Diff-Serv
information will be carried in whatever is "below" the Explicit Null information will be carried in whatever is "below" the Explicit Null
label stack entry, i.e., in the IP header DS bits or in the EXP bits label stack entry, i.e., in the IP header DS bits or in the EXP bits
of the next entry on the MPLS label stack. of the next entry on the MPLS label stack.
Naturally, this practice causes a problem if the Pipe Model LSP is Naturally, this practice causes a problem if the Pipe Model LSP is
being used to tunnel MPLS packets (i.e., if Condition L does not being used to tunnel MPLS packets (i.e., if Condition L does not
hold). With strict adherence to RFCs 3031 and 3036, this practice hold). With strict adherence to RFCs 3031 and 3036, this practice
results in an MPLS packet where Explicit NULL is at the top of the results in an MPLS packet where Explicit NULL is at the top of the
label stack, even though it is not the only entry in the label label stack, even though it is not the only entry in the label
stack. However, RFC 3032 makes this packet illegal. Some stack. However, RFC 3032 makes this packet illegal.
implementations simply transmit the illegal packet. Others try to
convert it to a legal packet by stripping off the Explicit NULL Some implementations simply transmit the illegal packet. Others try
to convert it to a legal packet by stripping off the Explicit NULL
before transmitting it. However, that breaks the Pipe Model by before transmitting it. However, that breaks the Pipe Model by
discarding the LSP Diff-Serv information. discarding the LSP Diff-Serv information. It is conceivable that
there may be an implementation which drops the illegal packet
entirely; this would also break the Pipe Model, as it would lose not
only the LSP Diff-Serv information but the entire packet.
Of course the LSP egress is not compelled to bind Explicit NULL to Of course the LSP egress is not compelled to bind Explicit NULL to
the tunnel's FEC; an ordinary label could be used instead. However, the tunnel's FEC; an ordinary label could be used instead. However,
using Explicit NULL enables the egress to determine immediately using Explicit NULL enables the egress to determine immediately
(i.e., without need for lookup in the Label Information Base) that (i.e., without need for lookup in the Label Information Base) that
the further forwarding of the packet is to be determined by whatever the further forwarding of the packet is to be determined by whatever
is below the label. Avoiding this lookup can have favorable is below the label. Avoiding this lookup can have favorable
implications on forwarding performance. implications on forwarding performance.
Removing the restriction that Explicit Null only occur at the bottom Removing the restriction that Explicit Null only occur at the bottom
of the stack is the simplest way to facilitate the proper operation of the stack is the simplest way to facilitate the proper operation
of the Pipe Model. of the Pipe Model.
4. Security Considerations 4. Deployment Considerations
Implementations which adhere to this specification will interoperate
correctly, and will correctly support the Pipe Model.
Implementations which do not adhere to this specification may not
interoperate. In particular if a router advertises a binding of
Explicit NULL, and if that router has an upstream LDP peer which will
not transmit a packet that has multiple label stack entries with
Explicit Null at top of the stack, then it will not be possible to
use Explicit NULL to support the Pipe Model until the upstream LDP
peer is brought into compliance with this specification.
It is possible that there may be a router implementation, preceding
this specification, which will discard any received packet with
multiple label stack entries and a top label value of Explicit Null.
It is advisable to configure any such routers so that they do not
advertise any bindings to Explicit Null.
5. Security Considerations
This document updates RFC 3032 by allowing Explicit NULL to occur at This document updates RFC 3032 by allowing Explicit NULL to occur at
any position in the label stack. This modification does not impose any position in the label stack. This modification does not impose
any new security considerations beyond those discussed in RFC 3032. any new security considerations beyond those discussed in RFC 3032.
5. Acknowledgments 6. Acknowledgments
Thanks to Rahul Aggarwal, Francois LeFaucheur, Yakov Rekhter, and Dan Thanks to Rahul Aggarwal, Francois LeFaucheur, Yakov Rekhter, and Dan
Tappan for their helpful comments. Tappan for their helpful comments.
6. Normative References 7. Normative References
[RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001 [RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001
7. Informative References 8. Informative References
[RFC3270] "Multi-Protocol Label Switching (MPLS) Support of [RFC3270] "Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", Le Faucheur, et. al., May 2002 Differentiated Services", Le Faucheur, et. al., May 2002
8. Author's Address 9. Author's Address
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com Email: erosen@cisco.com
9. Intellectual Property Notice 10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
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 that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
10. Copyright Notice
"Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to 11. Full Copyright Statement
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright (C) The Internet Society (2005). This document is subject
revoked by the Internet Society or its successors or assigns. to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/