Network Working Group Z. Li Internet-Draft X. Zeng Intended status: Standards Track Huawei Technologies Expires: January 5, 2015 July 4, 2014 Proxy MPLS Traffic Engineering Label Switched Path(LSP) draft-li-mpls-proxy-te-lsp-01 Abstract This document describes a method to setup MPLS TE proxy egress LSP which can help setup end-to-end LSP through stitching MPLS TE proxy egress LSP with BGP LSP in the Seamless MPLS network. The method is achieved by new Proxy Destination Object carried in RSVP-TE messages. 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 January 5, 2015. Copyright Notice Copyright (c) 2014 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 Li & Zeng Expires January 5, 2015 [Page 1] Internet-Draft Proxy MPLS TE LSP July 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Proxy Destination Object . . . . . . . . . . . . . . . . . . 5 5.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Seamless MPLS[I-D.ietf-mpls-seamless-mpls] provides an end to end service independent transport architecture. It removes the need for service specific configurations in network transport nodes. Seamless MPLS uses existing protocols like LDP, IS-IS, etc. to build intra- area segments and uses MP-BGP as the inter-area routing and label distribution protocol. In the typical Seamless MPLS architecture, LDP DoD are adopted to setup the segment LSP which is stitched with BGP LSP. When Seamless MPLS is applied to integrate the mobile backhaul network with the core/aggregation network, since MPLS TE is always adopted to deploy in the mobile backhaul network for requirements on high reliability, QoS, etc., it has to set up the MPLS TE proxy egress LSP in the mobile backhaul network to stitch with BGP LSP for the end-to-end transport. This document introduces a new Proxy Destination Object for RSVP-TE. Through the RSVP-TE extension the proxy egress LSP can setup for RSVP-TE. It makes possible to setup the end-to-end LSP when deploy MPLS TE in the Seamless MPLS scenario to integrate the mobile backhaul network with the core/aggregation network. Li & Zeng Expires January 5, 2015 [Page 2] Internet-Draft Proxy MPLS TE LSP July 2014 2. Terminology Proxy Egress LSP: It is defined in Sec. 4.1.4 of [RFC3031]. It is the LSP which is setup by the proxy egress LSR instead of the actual destination LSR. 3. Problem Statement The typical Seamless MPLS architecture is shown in the figure 1. The typical procedure of setting up the end-to-end transport LSP described in [I-D.ietf-mpls-seamless-mpls] is as follows: 1. Setup the access segment LSP from Access Node (AN) to Aggregation Node (AGN) using LDP with longest-match as defined in [RFC5283]. It requires only static routes and it is not necessary to know the actual destination (FEC of the LDP LSP); 2. The Aggregation Node (AGN) stitches the proxy egress LDP LSP with the BGP ingress LSP according to the key of FEC; 3. The remote Aggregation Node (AGN) setup the Ingress LDP LSP to remote Access Node (AN) which has the actual destination. 4. The remote Aggregation Node (AGN) stitches the egress BGP LSP with an ingress LDP LSP according to the key of FEC. LSPs set up with MPLS TE (RSVP-TE) provide a higher reliability and better QoS as compared to LSPs set up with LDP. So MPLS TE is always adopted to deploy in the mobile backhaul network. But when the mobile backhaul network integrates with the core network based on Seamless MPLS ([I-D.li-mpls-seamless-mpls-mbb]), it is difficult to setup end-to-end MPLS TE LSP spanning multiple domains. The possible way to setup the end-to-end LSP is that the proxy egress RSVP-TE LSP should be able to setup in the mobile backhaul network to stitch with BGP LSP at the Aggregation Node. 4. Solutions When setup a proxy egress RSVP-TE LSP in the Seamless MPLS scenario as shown in the Figure 1, there are two destination addresses to be carried by the RSVP-TE message: o Actual destination address: the actual destination address is the destination address of the end-to-end LSP for stitching the proxy egress LSP and the BGP LSP; Li & Zeng Expires January 5, 2015 [Page 3] Internet-Draft Proxy MPLS TE LSP July 2014 o Proxy destination address: the proxy destination address is the address of Aggregation Node which stitches the proxy egress RSVP- TE LSP and BGP LSP. When set up the proxy egress RSVP-TE LSP on the Access Node, it must specify the actual destination address and the proxy destination address. The Access Node needs to calculate the path based on the proxy destination address for the proxy egress RSVP-TE LSP. Then The Path message will be sent from the ingress node to the proxy destination node which is identified by the proxy destination address in the message. At the same time, the Path message carries the actual destination address of the LSP. When the proxy destination node receives the Path message, it sends back the Resv message to allocate label and reserve resource. And the proxy destination node can use the actual destination address to stitch BGP LSP which has the same address as the actual destination address of the proxy egress RSVP-TE LSP. | IGP X | | IGP Y | |(Access/Aggregation)| (Core) |Access/Aggregation)| |--------------------|--------------|-------------------| | | | | +-----+ +-----+ ...| AGN |.......| AGN |.... +----+ ........ +-----+ +-----+ ....... +----+ | AN |... ...| AN | +----+ ..... ..... +----+ ..... +-----+ +-----+ ..... ..| AGN |.......| AGN |.. +-----+ +-----+ | | Hierarchical | | | | BGP LSP | | | +--------------------+ | | MPLS TE LSP | | MPLS TE LSP | +-----------------+ +---------------+ | |--------------------| | | | MPLS LDP | | Figure 1 Seamless MPLS Scenario with MPLS TE In order to support setup of the proxy egress RSVP-TE LSP, the new Proxy Destination Object is introduced to carry the proxy destination address besides the actual destination address which is carried in the Session Object. Both the Session Object and the Proxy Li & Zeng Expires January 5, 2015 [Page 4] Internet-Draft Proxy MPLS TE LSP July 2014 Destination Object are carried in the RSVP-TE Path message and Resv message to set up the proxy egress LSP. 5. Proxy Destination Object 5.1. Format The Proxy Destination Object is an optional object which MAY be carried in Path or Resv Messages. The Proxy Destination Class-Number is TBD (of form 0bbbbbbb). RSVP-TE routers that do not support the object SHOULD reject the entire message and return an "Unknown Object Class" error. The format of the Proxy Destination Object is as follows: 1. IPv4 Proxy Destination Object 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 (TBD) | C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Proxy Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Proxy Destination Address: 32 bits. IPv4 address of the proxy destination node of the proxy egress RSVP-TE LSP. 2. IPv6 Proxy Destination Object 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 (TBD) | C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Proxy Destination Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Proxy Destination Address: 16 bytes. IPv6 address of the proxy destination node of the proxy egress RSVP-TE LSP. If a message contains multiple Proxy Destination Objects, only the first object is meaningful. Subsequent Proxy Destination Objects SHOULD be ignored and SHOULD NOT be propagated. Li & Zeng Expires January 5, 2015 [Page 5] Internet-Draft Proxy MPLS TE LSP July 2014 5.2. Procedures When the ingress LSR sets up the proxy egress LSP, the Proxy Destination Object MUST be inserted in the Path message to indicate the address of the proxy destination node and the actual destination address MUST be specified in the Session Object of the Path message. When receive the Resv messages, the ingress LSR SHOULD check if the Proxy Destination object is included. If the Path message includes the Proxy Destination object and the corresponding Resv message does not include this object, the ingress LSR MUST treat the Resv message as wrong messages and MUST NOT set up LSP. On the transit LSR, when receiving the messages with Proxy Destination object, it MUST include the Proxy Destination object in the outgoing Path or Resv message without change of the object. When it is necessary for the transit LSR to calculate the path, the proxy destination address identified by the Proxy Destination Object MUST be used instead of the actual destination address identified by the Session Object. If the transit LSR receives the Path message including the Proxy Destination object but receives the corresponding Resv message which does not include this object, it MUST treat the Resv message as wrong messages and MUST NOT set up LSP. On the egress LSR, when receiving Path messages with Proxy Destination object, it MUST include this object in the corresponding Resv message. 6. IANA Considerations IANA should allocate Class-Num and C-Type for IPv4 Proxy Destination Object and IPv6 Proxy Destination Object which are defined in this document. 7. Security Considerations This document does not introduce any additional security issues above those identified in [RFC3209]. 8. Acknowledgements The authors would like to thank Loa Andersson for his valuable comments and suggestions on this draft. 9. References Li & Zeng Expires January 5, 2015 [Page 6] Internet-Draft Proxy MPLS TE LSP July 2014 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 9.2. Informative References [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", draft- ietf-mpls-seamless-mpls-07 (work in progress), June 2014. [I-D.li-mpls-seamless-mpls-mbb] Li, Z., Li, L., Morillo, M., and T. Yang, "Seamless MPLS for Mobile Backhaul", draft-li-mpls-seamless-mpls-mbb-01 (work in progress), February 2014. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Xinzong Zeng Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zengxinzong@huawei.com Li & Zeng Expires January 5, 2015 [Page 7]