MPLS Working Group Z. Ali G. Swallow Internet Draft Cisco Systems, Inc. R. Aggarwal Juniper Networks Intended status: Standard Track August 17, 2011 Expires: February 16, 2012 Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-TE Label Switched Paths draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 16, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Expires February 2012 [Page 1]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract There are many deployment scenarios which require Egress Label Switching Router (LSR) to receive binding of the Resource ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched Path (LSP) to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to- point (P2P) and point-to-multipoint (P2MP) LSPs. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents Copyright Notice ..............................................1 1. Introduction ...............................................3 2. RSVP-TE signaling extensions ...............................4 2.1. Signaling non-PHP behavior ............................4 2.2. Signaling OOB Mapping Indication ......................5 2.3. Relationship between OOB and non-PHP flags ............7 2.4. Egress Procedure for label binding ....................7 3. Security Considerations ....................................8 4. IANA Considerations ........................................8 4.1. Attribute Flags for LSP_ATTRIBUTES object .............8 4.2. New RSVP error sub-code ...............................9 Expires February 2012 [Page 2]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 5. Acknowledgments ............................................9 6. References .................................................9 6.1. Normative References ..................................9 6.2. Informative References ...............................10 1. Introduction When Resource ReserVation Protocol Traffic Engineered (RSVP-TE) is used for applications like Multicast Virtual Private Network (MVPN) [MVPN] and Virtual Private LAN Service (VPLS) [RFC4761], an Egress Label Switching Router (LSR) receives the binding of the RSVP-TE Label Switched Path (LSP) to an application, and payload identification, using an "out-of-band" (OOB) mechanism (e.g., using Border Gateway Protocol (BGP)). In such cases, the Egress LSR cannot make correct forwarding decision until such OOB mapping information is received. Furthermore, in order to apply the binding information, the Egress LSR needs to identify the incoming LSP on which traffic is coming. Therefore, non Penultimate Hop Popping (non-PHP) behavior is required to apply OOB mapping. Non-PHP behavior requires the egress LSRs to assign a non-NULL label for the LSP being signaled. There are other applications that require non-PHP behavior. When RSVP-TE point-to-multipoint (P2MP) LSPs are used to carry IP multicast traffic non-PHP behavior enables a leaf LSR to identify the P2MP TE LSP, on which traffic is received. Hence the egress LSR can determine whether traffic is received on the expected P2MP LSP and discard traffic that is not received on the expected P2MP LSP. Non-PHP behavior is also required to determine the context of upstream assigned labels when the context is a MPLS LSP. Non-PHP behavior may also be required for MPLS-TP LSPs [RFC5921]. This document defines two new flags in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [RFC5420]: one flag for communication of non-PHP behavior, and one flag to indicate that the binding of the LSP to an application and payload identifier (payload-Id) needs to be learned via an out-of-band mapping mechanism. As there is one-to-one correspondence between bits in the Attribute Flags TLV and the RRO Attributes subobject, corresponding flags to be carried in RRO Attributes subobject are also defined. The procedures described in this document are equally applicable for P2P and P2MP LSPs. Specification of the OOB communication mechanism(s) is beyond the scope of this document. Expires February 2012 [Page 3]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 2. RSVP-TE signaling extensions This section describes the signaling extensions required to address the above-mentioned requirements. 2.1. Signaling non-PHP behavior In order to request non-PHP behavior for an RSVP-TE LSP, this document defines a new flag in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [RFC5420]: Bit Number (to be assigned by IANA): non-PHP behavior requested flag. In order to indicate to the Ingress LSR that the Egress LSR recognizes the "non-PHP behavior requested flag", the following new bit is defined in the Flags field of the Record Route object (RRO) Attributes subobject: Bit Number (same as bit number assigned for non-PHP behavior requested flag): Non-PHP behavior acknowledgement flag. An Ingress LSR sets the "non-PHP behavior requested flag" to signal the egress LSRs SHOULD assign non-NULL label for the LSP being signaled. This flag MUST NOT be modified by any other LSRs in the network. LSRs other than the Egress LSRs SHOULD ignore this flag. If an egress LSR receiving the Path message, supports the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also recognizes the "non-PHP behavior requested flag", it MUST allocate a non-NULL local label. The egress LSR MUST also set the "Non-PHP behavior acknowledgement flag" in the Flags field of the RRO Attribute subobject. If the egress LSR - supports the LSP_ATTRIBUTES object but does not recognize the Attributes Flags TLV; or - supports the LSP_ATTRIBUTES object and recognize the Attributes Flags TLV, but does not recognize the "non-PHP behavior requested flag"; Expires February 2012 [Page 4]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt then it silently ignores this request according to the processing rules of [RFC5420]. An ingress LSR requesting non-PHP behavior SHOULD examine "Non- PHP behavior acknowledgement flag" in the Flags field of the RRO Attribute subobject and MAY send a Path Tear to the Egress which has not set the "Non-PHP behavior acknowledgement flag". An ingress LSR requesting non-PHP behavior MAY also examine the label value corresponding to the Egress LSR(s) in the RRO, and MAY send a Path Tear to the Egress which assigns a Null label value. When signaling a P2MP LSP, a source node may wish to solicit individual response to the "non-PHP behavior requested flag" from the leaf nodes. Given the constraints on how the LSP_ATTRIBUTES may be carried in Path and Resv Messages according to RFC5420, in this situation the source node MUST use a separate Path message for each leaf in networks where [ATTRIBUTE-BNF] is not supported. In networks with [ATTRIBUTE-BNF] deployed either separate Path message for each leaf or multiple leafs per Path message MAY be used by the source node. 2.2. Signaling OOB Mapping Indication This document defines a single flag to indicate that the normal binding mechanism of an RSVP session is overridden. The actual out-of-band mappings are beyond the scope of this document. The flag is carried in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [RFC5420] and is defined as follows: Bit Number (to be assigned by IANA): OOB mapping indication flag. In order to indicate to the Ingress LSR that the Egress LSR recognizes the "OOB mapping indication flag", the following new bit is defined in the Flags field of the Record Route object (RRO) Attributes subobject: Bit Number (same as bit number assigned for OOB mapping indication flag): OOB mapping acknowledgement flag. Expires February 2012 [Page 5]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt An Ingress LSR sets the OOB mapping indication flag to signal the Egress LSR that binding of RSVP-TE LSP to an application and payload identification is being signaled out-of-band. This flag MUST NOT be modified by any other LSRs in the network. LSRs other than the Egress LSRs SHOULD ignore this flag. When an Egress LSR which supports the "OOB mapping indication flag", receives a Path message with that flag set, the Egress LSR MUST set the "OOB mapping acknowledgement flag" in the Flags field of the RRO Attribute subobject. The rest of the RSVP signaling proceeds as normal. However, the LSR MUST have received the OOB mapping before accepting traffic on the LSP. This implies that the Egress LSR MUST NOT setup forwarding state for the LSP before it receives the OOB mapping. Note that the payload information SHOULD be supplied by the OOB mapping. If the egress LSR receives the payload information from OOB mapping then the LSR MUST ignore L3PID in the Label Request Object [RFC3209]. If the egress LSR - supports the LSP_ATTRIBUTES object but does not recognize the Attributes Flags TLV; or - supports the LSP_ATTRIBUTES object and recognizes the Attributes Flags TLV, but does not recognize the "OOB mapping indication flag"; then it silently ignores this request according to the processing rules of [RFC5420]. An ingress LSR requesting OOB mapping SHOULD examine "OOB mapping acknowledgement flag" in the Flags field of the RRO Attribute subobject and MAY send a Path Tear to the Egress which has not set the "OOB mapping acknowledgement flag". When signaling a P2MP LSP, a source node may wish to solicit individual response to the "OOB mapping indication flag" from the the leaf nodes. Given the constraints on how the LSP_ATTRIBUTES may be carried in Path and Resv Messages according to RFC5420, in this situation the source node MUST use a separate Path message for each leaf in networks where [ATTRIBUTE-BNF] is not supported. In Expires February 2012 [Page 6]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt networks with [ATTRIBUTE-BNF] deployed either separate Path message for each leaf or multiple leafs per Path message MAY be used by the source node. In deploying applications where Egress LSR receives the binding of the RSVP-TE LSP to an application, and payload identification, using OOB mechanism, it is important to recognize that the OOB mapping is sent asynchronously with respect to the signaling of RSVP-TE LSP. Egress LSR only installs forwarding state for the LSP after it receives the OOB mapping. In deploying applications using OOB mechanism, an Ingress LSR may need to know when the Egress is properly setup for forwarding (i.e., has received the OOB mapping). How the Ingress LSR determines that the LSR is properly setup for forwarding at the Egress LSR is beyond the scope of this document. Nonetheless, if the OOB mapping is not received by the Egress LSR within a reasonable time, the procedure defined in section 2.4 to tear down the LSP is followed. 2.3. Relationship between OOB and non-PHP flags "Non-PHP behavior desired" and "OOB mapping indication" flags can appear and be processed independently of each other. However, as mentioned earlier, in the context of the applications discussed in this document, OOB mapping requires non-PHP behavior. An Ingress LSR requesting the OOB mapping MAY also set the "non-PHP behavior requested flag" in the LSP_ATTRIBUTES object in the Path message. 2.4. Egress Procedure for label binding RSVP-TE signaling completion and the OOB mapping information reception happen asynchronously at the Egress. As mentioned in Section 2.2, Egress waits for the OOB mapping before accepting traffic on the LSP. Nonetheless, MPLS OAM mechanisms, e.g., LSP Ping and Trace route as defined in [RFC4379], [P2MP-OAM], are expected to work independent of OOB mapping learning process. In order to avoid unnecessary use of the resources and possible black-holing of traffic, an Egress LSR MAY send a Path Error message if the OOB mapping information is not received within a reasonable time. This Path Error message SHOULD include the error code/sub-code "Notify Error/ no OOB mapping received" for all affected LSPs. If notify request was included when the LSP was initially setup, Notify message (as defined in [RFC3473]) MAY also be used for delivery of this information to the Ingress LSR. An Egress LSR MAY implement a cleanup timer for this purpose. The Expires February 2012 [Page 7]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt time-out value is a local decision at the Egress, with a RECOMMENDED default value of 60 seconds. 3. Security Considerations Addition of "non-PHP behavior" adds a variable of attacks on the label assigned by the Egress node. As change in the value of the egress label reported in the RRO can cause the LSP to be torn down, additional security considerations for protecting label assigned by the Egress node are required. Security mechanisms as identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5420] and [RFC4875] can be used for this purpose. This document does not introduce any additional security issues above those identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5420] and [RFC4875]. 4. IANA Considerations The following changes to the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry are required. 4.1. Attribute Flags for LSP_ATTRIBUTES object The following new flags are defined for the Attributes Flags TLV in the LSP_ATTRIBUTES object. The numeric values are to be assigned by IANA. o Non-PHP behavior flag: This flags is used in the Attributes Flags TLV in a Path message. The flags have corresponding new flag to be used in the RRO Attributes subobject. As per [RFC5420], the bit numbering in the Attribute Flags TLV and the RRO Attributes subobject is identical. That is, the same attribute is indicated by the same bit in both places. This flag is not allowed in the Attributes Flags TLV in a Resv message. Specifically, Attributes of this flag are as follows: - Bit Number: To be assigned by IANA. - Attribute flag carried in Path message: Yes - Attribute flag carried in Resv message: No - Attribute flag carried in RRO message: Yes Expires February 2012 [Page 8]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt o OOB mapping flag: This flags is used in the Attributes Flags TLV in a Path message. The flags have corresponding new flag to be used in the RRO Attributes subobject. As per [RFC5420], the bit numbering in the Attribute Flags TLV and the RRO Attributes subobject is identical. That is, the same attribute is indicated by the same bit in both places. This flag is not allowed in the Attributes Flags TLV in a Resv message. Specifically, Attributes of this flag are as follows: - Bit Number: To be assigned by IANA. - Attribute flag carried in Path message: Yes - Attribute flag carried in Resv message: No - Attribute flag carried in RRO message: Yes 4.2. New RSVP error sub-code For Error Code = 25 "Notify Error" (see [RFC3209]) the following sub-code is defined. Sub-code Value -------- ----- No OOB mapping received to be assigned by IANA. 5. Acknowledgments The authors would like to thank Yakov Rekhter for his suggestions on the draft. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Expires February 2012 [Page 9]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt [RFC5420] A. Farrel, D. Papadimitriou, J. P. Vasseur and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", RFC 5420, February 2006. [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al, "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", RFC 4875. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.. [RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) - - Version 1 Functional Specification", RFC 2205, September 1997. [ATTRIBUTE-BNF] Berger, L. and Swallow, G., "LSP Attributes Related Routing Backus-Naur Form", draft-ietf-ccamp-attribute- bnf, work in progress. 6.2. Informative References [MVPN] E. Rosen, R. Aggarwal et al, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10.txt, work in progress. [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC5921] M. Bocci, S. Bryant, et al, "A Framework for MPLS in Transport Networks", RFC 5921, January 2007. [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Expires February 2012 [Page 10]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt [RFC4379] K. Kompella, and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [P2MP-OAM] S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau, "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping", draft-ietf-mpls-p2mp- lsp-ping-17.txt, work in progress. Author's Addresses Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com George Swallow Cisco Systems, Inc. Email: swallow@cisco.com Rahul Aggarwal Juniper Networks rahul@juniper.net Expires February 2012 [Page 11]