Network Working Group Z. Li Internet-Draft L. Zheng Intended status: Standards Track Huawei Technologies Expires: April 24, 2014 October 21, 2013 LDP and RSVP-TE Extensions for Label Stack Distribution draft-li-mpls-label-stack-distribution-00 Abstract This document defines the necessary extension for LDP and RSVP-TE to distribute more than one label (label stack) for specific FEC between label distribution peers. Requirements Language 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]. 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 April 24, 2014. Copyright Notice Copyright (c) 2013 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 Li & Zheng Expires April 24, 2014 [Page 1] Internet-Draft LDP & RSVP-TE Label Stack October 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Label Stack/FEC Binding . . . . . . . . . . . . . . . . . . . 2 3. LDP Label Stack TLV . . . . . . . . . . . . . . . . . . . . . 3 4. RSVP-TE Label Stack Object . . . . . . . . . . . . . . . . . 4 5. Data Plane Processing of Label Stack . . . . . . . . . . . . 4 5.1. Upstream LSR . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Downstream LSR . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The MPLS architecture [RFC3031] defines a label distribution protocol is a set of procedures by which one LSR informs another of the label/ FEC bindings it has made. LDP [RFC5036] and RSVP-TE [RFC3209] are two protocols defined for distributing labels. For specific FEC, both LDP and RSVP-TE distribute only one label. As the application based on MPLS develops, there proposes requirements to allocate more than one label for a specific FEC. This document discusses the possible usage of allocation of more than one label and defines the corresponding protocol extensions of LDP and RSVP-TE 2. Label Stack/FEC Binding [RFC3107] defines how BGP is used to distribute MPLS label binding when BGP is used to distribute a particular route. Label mapping information is carried as part of the Network Layer Reachability Information (NLRI) in the Multiprotocol Extensions attributes. Unlike the one label/FEC binding for LDP and RSVP-TE, one or more labels could be carried in the NLRI. The label stack allocating for a specific FEC can be useful in the following situations: - Other than the tunnel label, the extra label in the label stack could be used for load balancing on the downstream LSR - the extra label in the label stack could be used for QoS on the downstream LSR Li & Zheng Expires April 24, 2014 [Page 2] Internet-Draft LDP & RSVP-TE Label Stack October 2013 - the multiple labels can be combined to form a big label or be used as the context label for forwarding In addition, the labels in the allocated label stack can be only explained by the downstream LSR's own. That is, the upstream LSR does not need to be aware of the meaning of each label in the label stack. This can achieve great extensibility. 3. LDP Label Stack TLV [RFC5036] defines several different kinds of Label TLVs. This document defines a new type of LDP Label TLV, the LDP Label Stack TLV. The LDP Label Stack TLV, same as other types of Label TLVs, is carried by the messages used to advertise, request, release, and withdraw label mappings. The encoding of the LDP Label Stack TLV is as follows. The Label Stack TLV type is to be allocated by IANA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Label Stack (TBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label n (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. LDP Label Stack TLV Each label is represented as a 20-bit number in a 4 octet field as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Li & Zheng Expires April 24, 2014 [Page 3] Internet-Draft LDP & RSVP-TE Label Stack October 2013 4. RSVP-TE Label Stack Object This documents defines a new RSVP-TE object, the RSVP-TE Label Stack Object. Label Stack Object MAY be carried in Resv messages. Different from the Label Object defined in [RFC3209], the contents of a Label Stack Object is multiple labels, encoded in 4 octets respectively. The encoding of the RSVP-TE Label Stack Object including the common object header is as follows, the C_Type is to be allocated by IANA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type(TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label n (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. RSVP-TE Label Stack Object 5. Data Plane Processing of Label Stack This section defines data plane processing of Label Stack on upstream and downstream LSR. 5.1. Upstream LSR Suppose upstream LSR is capable of processing label stack/FEC binding. Suppose upstream LSR and Downstream LSR have agreed to bind Label Stack LS to FEC F, for packets sent from upstream LSR to Downstream LSR. Before a packet is sent from upstream LSR to Downstream LSR, the whole Label Stack LS SHOULD be pushed on to the packet. 5.2. Downstream LSR Li & Zheng Expires April 24, 2014 [Page 4] Internet-Draft LDP & RSVP-TE Label Stack October 2013 When the labeled packet arrives at the downstream LSR, the whole Label Stack LS SHOULD be processed by the downstream LSR. The Label Stack LS will be either popped out or replaced by new label or Label Stack. How the Label Stack LS is used on downstream LSR can be a local manner. But the label in the Label Stack LS MUST NOT leak to the downstream LSR by this downstream LSR. That is, partial decapsulation of the Label Stack are not permitted. 6. IANA Considerations The IANA is requested to assign a new TLV from the "TLV Type Name Space " registry. Value Meaning Reference ----- ------------------- --------- TBA LDP Label Stack TLV this document (sect 4) The IANA is requested to assign a new C-Type from the "Class Type " registry. Value Meaning Reference ----- ------------------ --------- TBA RSVP-TE Label Stack this document (sect 5) 7. Security Considerations TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Li & Zheng Expires April 24, 2014 [Page 5] Internet-Draft LDP & RSVP-TE Label Stack October 2013 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. 8.2. Informative References [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Lianshu Zheng Huawei Technologies Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China Email: vero.zheng@huawei.com Li & Zheng Expires April 24, 2014 [Page 6]