Network Working Group Zhenbin Li Internet-Draft Lei Li Intended status: Informational Huawei Technologies Expires: August 17, 2014 Manuel Julian Lopez Morillo Vodafone Group Networks Tianle Yang China Mobile February 13, 2014 Seamless MPLS for Mobile Backhaul draft-li-mpls-seamless-mpls-mbb-01 Abstract This document introduces the framework of Seamless MPLS to integrate the mobile backhaul network with the core network. New requirements of Seamless MPLS for mobile backhaul networks are defined and corresponding solutions are proposed. 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 August 17, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Zhenbin Li, et al. Expires August 17, 2014 [Page 1] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Scenarios for Network Architecture . . . . . . . . . . . 4 3.2. Scenarios for Different Edge of Labeled BGP . . . . . . . 6 4. Requirements and Solutions . . . . . . . . . . . . . . . . . 9 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Auto Mesh and Enhancement . . . . . . . . . . . . . . 12 4.2.2. Service-Driven Tunnel . . . . . . . . . . . . . . . . 13 4.2.3. Auto Path Computation . . . . . . . . . . . . . . . . 13 4.3. Access Stitching . . . . . . . . . . . . . . . . . . . . 14 4.3.1. Transport Layer Stitching . . . . . . . . . . . . . . 14 4.3.2. Service Layer Stitching technology . . . . . . . . . 15 4.4. Reliability . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.1. MRT FRR based on LDP MT . . . . . . . . . . . . . . . 18 4.5. Policy Control . . . . . . . . . . . . . . . . . . . . . 18 4.6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6.1. L3VPN PM . . . . . . . . . . . . . . . . . . . . . . 19 4.6.2. IPFPM (IP Flow Performance Measurement) . . . . . . . 19 4.6.3. Service Path Visualization . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Seamless MPLS [I-D.ietf-mpls-seamless-mpls] describes an architecture which can be used to extend MPLS networks to integrate access and core/aggregation networks into a single MPLS domain. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. One of the key elements of Seamless MPLS Zhenbin Li, et al. Expires August 17, 2014 [Page 2] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 is the separation of the service and transport plane: it can reduce the service specific configurations in network transport node. The main purpose of Seamless MPLS is to deal with the integration of access networks and core/aggregation networks. The typical access devices taken into account are DSLAM(Digital Subscriber Link Access Multiplexer), etc. Now the mobile backhaul service has been deployed widely, the requirement of the integration of mobile backhaul networks and core networks has been proposed. Though some approaches of Seamless MPLS can be reused for the integration, there has to be some new issues to be dealt with when integrate these networks based on MPLS technologies. This document describes new requirements and solutions for Seamless MPLS to extend the core domain to integrate the mobile backhaul networks. It can enable a flexible deployment of an end to end mobile backhaul service delivery. Though the Seamless MPLS approach for the integration of the core network and the mobile network tries to use existing and well known protocols, some new features or protocol extensions have to be introduced for the integrated network to provide the unified service. Currently, this document focuses on end to end unicast LSP. Multicast will be described in the future version. 2. Terminology This document uses the following terminology: o ABR: Area Border Router o ASBR: AS Border Router o ASG: Aggregation Site Gateway o CSG: Cell Site Gateway o LFA: Loop Free Alternate o NPE: Network Provider Edge o PE: Provider Edge o RNC: Radio Network Controller o RSG: RNC Site Gateway o SPE: Switching Provider Edge Zhenbin Li, et al. Expires August 17, 2014 [Page 3] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 o UPE: Under Provider Edge 3. Scenarios Existing mobile backhaul networks have different topology and network architectures composed by devices with variable capability . Seamless MPLS should be able to adapt to different scenarios to support the integration of mobile backhaul networks. 3.1. Scenarios for Network Architecture Mobile backhaul networks are usually built using hierarchical network structure with access network, aggregation network and core network. These networks are always separated by AS or IGP area. Along with the progress of network integration, the integration network can be summarized as following scenarios. Network Architecture 1: Network separated by ASes In current networks it is common that the core network and the mobile backhaul network have different AS numbers. The core network usually uses a public AS number for internet connection. On the other hand the mobile backhaul network including access network and aggregation network usually uses a private AS number just for local services. So the integrated end-to-end service means to across different ASes. Scenario 1: ASes connected by different ASBRs This is the most common scenario. In this scenario there are redundant ASBRs in each AS to connect with the other AS back to back. | Service | |------------------------------------------------------| | AS-X | | AS-Y | |(Access/Aggregation)| | (Core) | |--------------------| |------------------| | | | +-----+ +-----+ ...|ASBR1|-------|ASBR3|.... +----+ ........ +-----+ +-----+ ....... +----+ | PE |... ...| PE | +----+ ..... ..... +----+ ..... +-----+ +-----+ ..... ..|ASBR2|-------|ASBR4|.. +-----+ +-----+ Figure 1 Redundant ASBRs connected Back to Back Zhenbin Li, et al. Expires August 17, 2014 [Page 4] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 The transport layer of Seamless MPLS for this scenario is the same as the Option C Inter-AS VPN scenario defined by [RFC4364]. In this scenario, Seamless MPLS uses label distribution enabled IBGP and EBGP to establish the end-to-end BGP LSP to support services (using IPv4 as the example). o IBGP distributes the PE's 32/ route to ASBRs in source AS (P devices need not know the PE's 32/ route). o EBGP redistributes labeled IPv4 routes from source AS to neighboring AS. o IBGP distributes the PE's 32/ route from ASBRs to ingress PEs in target AS. Scenario 2: ASes connected by integrated ASBRs In this scenario there are still redundant ASBRs in each AS. But these ASBRs integrates together to reduce a pair of devices. This scenario can effectively reduce the number of devices and costs. Other devices in each AS such as PEs and Ps need not be impacted. | Service | |----------------------------------------| | AS-X | AS-Y | |(Access/Aggregation)| (Core) | |--------------------|-------------------| | | | +-----+ ....ASBR1|.... +----+ ........ +-----+ ....... +----+ | PE |... ...| PE | +----+ ..... ..... +----+ ..... +-----+ ..... ...ASBR2|.. +-----+ Figure 2 Integrated ASBRs The transport layer of Seamless MPLS for this scenario is similar with the network architecture 1 (using IPv4 as the example). o The same in each AS domain. Still use IBGP to distribute the PE's 32/ routes. o The integrated ASBR should support two different ASes and can redistribute the labeled IPv4 routes from one AS to neighboring AS. Zhenbin Li, et al. Expires August 17, 2014 [Page 5] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 Network Architecture 2: Different network integrated in one AS but separated by different IGP areas This scenario is far different from most of current mobile backhaul networks. Core network is deployed in a same AS with access/ aggregation network. The core network, aggregation network and access network are just separated by IGP areas for scalability. | Service | |----------------------------------------| | AS | |----------------------------------------| | IGP-X | IGP-Y | |(Access/Aggregation)| (Core) | |--------------------|-------------------| | | | +----+ ... |ABR1|.... +----+ ........ +----+ ....... +----+ | PE |... ...| PE | +----+ ..... ..... +----+ ..... +----+ ..... ...|ABR2|.. +----+ Figure 3 Integrated network in one AS In this scenario, Seamless MPLS uses labeled IBGP to establish the end-to-end BGP LSP to support services. 3.2. Scenarios for Different Edge of Labeled BGP Devices in existing mobile backhaul networks vary in capacity. Labeled BGP capability may not be able to be supported by all devices, especially by lower level nodes in access network. Seamless MPLS based on labeled BGP technology should adapt to different situations. Based on the location of the edge of labeled BGP, there should be three possible scenarios. Scenario 1: Cell Site/User PE devices as the edge of labeled BGP The transport layer in this scenario should be totally end-to-end BGP LSP. The scenario requires the ingress PE(access devices) to encapsulate a three-label stack on the packet. This requirement maybe difficult to be satisfied by all kinds of access devices, especially access devices with very low capacity. Zhenbin Li, et al. Expires August 17, 2014 [Page 6] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 | AS-X | | AS-Y | |(Access/Aggregation)| | (Core) | |--------------------| |-------------------| | | | | +-----+ +-----+ ...|ASBR1|-------|ASBR3|.... +----+ ........ +-----+ +-----+ ....... +----+ | PE |... ...| PE | +----+ ..... ..... +----+ ..... +-----+ +-----+ ..... ..|ASBR2|-------|ASBR4|.. +-----+ +-----+ | | | Hierarchical BGP LSP | +--------------------+--------------+------------------+ | | | | +--------------------+--------------+------------------+ | MPLS LDP/TE | MPLS LDP/TE | MPLS LDP/TE | | | | | Figure 4 Labeled BGP ended at access devices Scenario 2: ASG nodes as the edge of labeled BGP In this scenario, access nodes(PEs) directly connected with eNodeB can not support labeled BGP. Access nodes only support basic MPLS functionality with basic route functionality using static or default routes. ASG devices should stitch MPLS LDP/TE LSP in access network and BGP LSP in aggregation/core network to support end-to-end services. Zhenbin Li, et al. Expires August 17, 2014 [Page 7] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 | AS-X | | AS-Y | |(Access/Aggregation)| | (Core) | |--------------------| |-------------------| | | | | +----+ +-----+ +-----+ |ASG | ...|ASBR1|-------|ASBR3|.... +----+ .+----+. +-----+ +-----+ ... +----+ | PE |... .....| PE | +----+ ..+----+ .. +----+ |ASG |.. +-----+ +-----+ ..... +----+ ..|ASBR2|-------|ASBR4|.. +-----+ +-----+ | | | | | | |Labeled IBGP|Labeled EBGP| Labeled IBGP | | +------------+------------+---------------------+ +-----------+ | | | |MPLS LDP/TE+------------+ +---------------------+ | | MPLS LDP/TE| | MPLS LDP/TE | | | | | | Figure 5 Labeled BGP ended at ASG(P) devices Scenario 3: RSG(ASBR) devices as the edge of labeled BGP In this scenario devices in the access and aggregation network just support basic MPLS functionality. ASBR nodes should stitch MPLS LDP/ TE LSP in access/aggregation network and BGP LSP in core network for end-to-end service across different domains. Zhenbin Li, et al. Expires August 17, 2014 [Page 8] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 | AS-X | | AS-Y | |(Access/Aggregation)| | (Core) | |--------------------| |-------------------| | | | | +-----+ +-----+ ...|ASBR1|-------|ASBR3|.... +----+ ........ +-----+ +-----+ ....... +----+ | PE |... ...| PE | +----+ ..... ..... +----+ ..... +-----+ +-----+ ..... ..|ASBR2|-------|ASBR4|.. +-----+ +-----+ | | | | | | Labeled EBGP | Labeled IBGP | | +--------------+------------------+ +--------------------+ +------------------+ | MPLS LDP/TE | | MPLS LDP/TE | Figure 6 Labeled BGP ended at ASBRs 4. Requirements and Solutions 4.1. Overview The typical mobile backhaul network is shown in the figure 1. It usually adopts ring topology to save fiber resource and it is divided into the aggregate network and the access network. Cell Site Gateways(CSGs) connects the eNodeBs and RNC Site Gateways(RSGs) connects the RNCs. The mobile traffic is transported from CSGs to RSGs. Zhenbin Li, et al. Expires August 17, 2014 [Page 9] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 ---------------- / \ / \ / \ +------+ +----+ Access +----+ |eNodeB|---|CSG1| Ring 1 |ASG1|------------- +------+ +----+ +----+ \ \ / \ \ / +----+ +---+ \ +----+ |RSG1|----|RNC| -------------| | Aggregate +----+ +---+ |ASG2| Ring | -------------| | +----+ +---+ / +----+ |RSG2|----|RNC| / \ +----+ +---+ / \ / +------+ +----+ Access +----+ / |eNodeB|---|CSG2| Ring 2 |ASG3|------------ +------+ +----+ +----+ \ / \ / \ / ----------------- Figure 7 Mobile Backhaul Network Seamless MPLS [I-D.ietf-mpls-seamless-mpls] defines the possible requirements for the integration of the access network and the aggregation/core network. In the mobile backhaul network, being different from the typical access devices(DSLAM, MSAN), CSGs and RSGs of the mobile backhaul network needs to support rich MPLS features such as path design, protection switch, OAM, etc., to provide SDH- like service. On the other hand, CSGs have the same scalability limitations as access devices. Seamless MPLS for mobile backhaul has to take into account the difference and the similarity and new requirements are proposed. 1. Requirements on MPLS TE In the mobile backhaul network, in order to provide SDH-like service, MPLS TE or MPLS TP technologies are always introduced besides MPLS LDP. When integrate the core network and the mobile backhaul network, the interworking between IGP/BGP and RSVP-TE is inevitable. There are following requirements: -- Proxy Egress LSP and BGP LSP Stitching: When the end-to-end LSP setup in the Seamless MPLS domain, MPLS TE LSP in the mobile backhaul should be stitched with the BGP LSP in the core network. In Zhenbin Li, et al. Expires August 17, 2014 [Page 10] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 addition, since the end-to-end MPLS TE LSP cannot setup spanning multiple areas, the proxy egress RSVP-TE LSP should be able to setup in the mobile backhaul network. -- OAM: There are complete OAM solutions for MPLS TE/MPLS-TP including fault management(FM) and performance monitoring(PM). For IGP/BGP, the OAM mechanism, especially the performance monitoring mechanism is not enough. Thus the end-to-end OAM for the mobile backhaul service can not be provided. The Seamless MPLS architecture should propose unified OAM mechanisms to satisfy the requirements of the end-to-end services. -- Protection: The protection switch mechanism has been provided in the mobile backhaul network to achieve convergence in 50ms. When integrate the core network, the end-to-end convergence in 50 ms should be guaranteed. -- Scalability: Comparing with MPLS LDP, there exists more scalability issues for MPLS TE. Though the network scale can be controlled by dividing the network into multiple IGP areas in the Seamless MPLS domain, there is more complex configuration for MPLS TE than MPLS LDP since the rich MPLS TE properties should be specified. The provision issue has much negative effect on the scalability of MPLS-TE-based network. 2. Requirements on Ring Network In mobile backhaul network, CSGs always access the ring network. The approaches proposed in the [I-D.ietf-mpls-seamless-mpls] face challenges in the ring network. -- LDP DoD: There exists multiple nodes from a CSG to an ASG in the ring network. This means label request messages and label mapping messages should be sent through multiple nodes for LDP DoD. If static routes are used, there are a great deal of routes which should be configured statically in the network. This provision is hard to be accepted by the service provider. -- LFA(Loop Free Alternate): The route loop will be bound to happen in the ring network. This means that the backup route does not exist in specific nodes of the ring network according to LFA. If LDP is used and convergence in 50 ms must be guaranteed for the mobile backhaul service, the new FRR solution must be proposed to cover the whole network. 3. Requirements on L3VPN Zhenbin Li, et al. Expires August 17, 2014 [Page 11] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 FMC( Fixed Mobile Convergence ) is being taken into account for the mobile backhaul network. In order to achieve higher scalability, L3VPN is provisioned to bear the mobile backhaul service besides PW. There are following requirements: -- Policy control: The routes in the L3VPN can be advertised in a larger scope comparing with the point-to-point PW setup in the L2VPN. Considering the limited capability of the access devices (CSGs), complex policy control on route advertisement has to be introduced. This cause the provision becomes complex and error-prone. Simplifying the policy control is mandatory in the Seamless MPLS domain. -- L3VPN OAM: There exists mature OAM mechanism based on PW for L2VPN. The similar mechanism should be provided for the L3VPN to satisfy the SDH-like OAM requirement for the mobile backhaul service. 4.2. Scalability [I-D.li-mpls-serv-driven-co-lsp-fmwk] describes the massive configuration issue for MPLS TE. As the mobile backhaul service develops and the network scale expands, more and more LTE eNodeBs and associated Cell Site Gateways(CSGs) are added in the networks to connect the RNCs and associated RNC site gateways(RSGs). This proposes the requirement of a great deal of MPLS TE tunnels which connect CSGs and RSGs. Calculated using the typical MPLS TE tunnel configuration, there will be hundreds of thousands of command lines need to be configured for MPLS TE. In addition, the return path issue for BFD for LSP will deteriorate the configuration work since the configuration is necessary to guarantee the return the path is the same as the forward path for MPLS TE tunnels. Comparing with LDP, the provision work for MPLS TE is time-consuming and error-prone which has much negative effect on the scalability. When Seamless MPLS is applied to the mobile backhaul network, the scalability of MPLS TE must be improved by effective solutions. 4.2.1. Auto Mesh and Enhancement [RFC4972] proposes an automatic discovery mechanism to discover the set of LSR members of a mesh in order to automate the creation of mesh of TE LSPs. Through Interior Gateway Protocol (IGP) routing extensions, the LSRs members of a specific mesh can be discovered. Then the LSR can trigger setup of MPLS TE tunnels to other LSRs of the same mesh. [I-D.li-ccamp-role-based-automesh] proposes the optimization for the auto mesh mechanism. In some application scenarios, it is not necessary to setup full mesh MPLS TE tunnels. The optimized auto mesh mechanism is to not only advertise the membership of a mesh, but also advertise the role of the member. Zhenbin Li, et al. Expires August 17, 2014 [Page 12] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 Thus the MPLS TE tunnel can setup based on both the membership and the role. It can save the unnecessary setup of MPLS TE tunnels. 4.2.2. Service-Driven Tunnel [I-D.li-mpls-serv-driven-co-lsp-fmwk] proposes the service-driven mechanism and framework for setup of MPLS TE tunnels. LDP LSP has advantage over MPLS TE in scalability since LDP LSP setup is topology-driven which is a scalable way to adapt to the large-scale network. On the other hand, MPLS TE LSP is always setup to bear specific services such as L3VPN and L2VPN. That is, MPLS TE LSPs will not be setup aimlessly which is always inevitable for MPLS topology-driven LSP if there is no policy exerted on it. So the service-driven mechanism is proposed to trigger MPLS TE LSP setup automatically by the service instead of explicitly configuring each tunnel and its traffic engineering attributes. The service-driven method also has much advantage in the process of setting up co-routed TE LSPs. The mobile backhaul service transported by MPLS TE LSPs is always bi-directional. The characteristic can be utilized to setup the forward MPLS TE LSP and the co-routed reverse MPLS TE LSP. The details of the procedures can refer to [I-D.li-mpls-serv-driven-co-lsp-fmwk]. 4.2.3. Auto Path Computation No matter the auto mesh mechanism or the service-driven mechanism is used to automate the creation of MPLS TE LSPs, several set of MPLS TE properties need to be specified for these MPLS TE tunnels. If a group of tunnels can share one set of MPLS TE properties, they can be triggered to setup automatically. On the contrary, if there are distinct MPLS TE properties for MPLS TE tunnels, the configuration work can not be saved since even if the auto tunnel mechanism is adopted the MPLS TE properties has to be configured for each tunnel which is like the current explicit configuring of traffic engineering properties of a tunnel. For MPLS TE, the explicit path is such a tough thing which can have negative effect on the auto tunnel mechanism. [I-D.li-ospf-auto-mbb-te-path] describes the scenarios of the mobile backhaul service in which the explicit path has to be used. Accordingly TA (TE Area) and TL(TE Layer) are introduced for the design of MPLS TE network view. Thus less MPLS TE properties need to be specified for MPLS TE tunnels and automation of path computation can be improved. As a result the auto tunnel mechanism can be applied to improve the scalability of MPLS TE. Zhenbin Li, et al. Expires August 17, 2014 [Page 13] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 4.3. Access Stitching To reduce the requirement on lower level network devices( access nodes/ ASG nodes, etc.) and keep these devices as simple as possible, the MPLS stitching technology should be deployed at the edge of labeled BGP nodes. Thus nodes under the stitching points just need to support basic MPLS function with IGP or even just static routes. The position of the stitching point has been discussed in section 3.2. This section introduces the stitching solutions. 1. Transport layer stitching. This kind of stitching technology ensures the transport LSP can setup end to end. The service is just to deploy at the end points and the transit nodes in network need not perceive services. 2. Service layer stitching. This kind of stitching technology establishes a hierarchical service end to end. This technology can reduce the load of service session on access nodes. But the stitching nodes need to perceive services. 4.3.1. Transport Layer Stitching Transport layer stitching technology can stitch multi-segment transport LSPs together to establish an end-to-end LSP. 4.3.1.1. Proxy TE In mobile backhaul network MPLS TE has been adopted to provide SDH- like service. When the end-to-end LSP setup in the Seamless MPLS domain, MPLS TE LSP in the mobile backhaul network should be stitched with the BGP LSP in the core network. [I-D.li-mpls-proxy-te-lsp] proposes the solution to setup proxy egress LSP by RSVP-TE. When setup such LSP, there are two addresses will be carried by RSVP-TE Path/Resv messages: the actual destination address and the proxy node address. RSVP-TE Path message will be sent along the path to the proxy node instead of the actual destination node. When Path messages arrives at the proxy node, it will send back Resv message to allocate label and reserve resource. The proxy node can use the actual destination address advertised by the Path message to stitch with BGP LSP. With Proxy TE, the path for the LSP is calculated with the proxy node as the destination instead of its actual destination. So the MPLS TE information related with the path to the actual destination is not necessary to flood in the mobile backhaul network. This reduces the state maintenance and process burden of access nodes. Zhenbin Li, et al. Expires August 17, 2014 [Page 14] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 4.3.1.2. Proxy LDP DoD If LDP DoD is adopted for Seamless MPLS in the mobile haul network, since there are multiple hops from the CSG to ASG or RSG, it is troublesome to configure static routes to a specific destination on all nodes. Like Proxy TE, LDP can also setup proxy egress LSP by specifying the proxy node. When setup such LSP, there are two addresses will be carried by LDP Label Request/Label Mapping messages: the actual destination address and the proxy node address. LDP Label Request message will be sent along the path to the proxy node instead of the actual destination node. When Label Request messages arrives at the proxy node, it will sent back Label Mapping message to allocate label. The proxy node can use the actual destination address advertised by the Label Request message to stitch with BGP LSP. With Proxy LDP, the route for the proxy node will be used to setup LSP for the actual destination. So the static routes for the actual destination are not necessary in the mobile backhaul network. This reduces the route number and process burden of access nodes. 4.3.2. Service Layer Stitching technology There is another stitching technology, which is not only just stitching transport layer but also stitching the service layer to help establish services across different domains. Service layer stitching technology should coexist with common services in an MPLS network. Zhenbin Li, et al. Expires August 17, 2014 [Page 15] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 +----+ +-----+ +-----+ ..|SPE | ...|ASBR1|-------|ASBR3|.... +----+ .... .+----+. +-----+ +-----+ +----+ | UPE|.. ... ...| PE | +----+ .....+----+ . +----+ ..SPE |. . +-----+ +-----+ .. +----+ ..|ASBR2|-------|ASBR4|.. +-----+ +-----+ | Hierarchy End-to-End Service | | | | Service1 | Service2 | +-----------+-----------------------------------------+ | | | | | | |Labeled IBGP|Labeled EBGP| Labeled IBGP | | +------------+------------+---------------+ | | | | | +-----------+------------+ +---------------+ |MPLS LDP/TE| MPLS LDP/TE| | MPLS LDP/TE | | | | | | Figure 8 Architecture of Service Layer Stitching The general architecture of service layer stitching is shown in figure 8. The service stitching technologies are related with different service types. 4.3.2.1. L3 Service Stitching - Hierarchy of VPN (HoVPN) Hierarchy of VPN (HoVPN) can stitching two segment VPN in one domain together to establish a VPN service across different domains and simplify the process of access devices (AN/CSG). 1. Process of Control Plane o UPEs provide the access service for users. These UPEs act as CSG/ AN to maintain the VPNv4 routes of the directly connected VPN sites and just default VPNv4 routes advertised from SPEs. For transport layer UPEs just maintain LSPs to SPEs instead of establishing Hierarchical LSPs to all remote PEs. For service layer UPEs just establish VPNv4 MP-BGP session with SPEs instead of establishing them with all remote PEs. o SPEs maintain all VPNv4 routes of the VPN sites connected through the UPEs and PEs, including the routes from the local and the remote sites. Instead of advertising routes from the remote sites to the UPEs, the SPE only advertises the default route carrying label to the UPEs for the specific VPN instance. SPEs establish Zhenbin Li, et al. Expires August 17, 2014 [Page 16] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 hierarchy LSPs through labeled BGP to all other PEs and basic LSPs /CR-LSPs through MPLS LDP/RSVP-TE to UPEs. 2. Process of Forwarding Plane o UPEs stack two layer labels for packets to SPEs. The bottom label is assigned by the SPE and it is associated with the default route in a particular VRF. The top label is assigned by the UPE's IGP Next Hop, which is associated with to the /32 route to the SPE. o When packets from UPEs arrive at SPEs, the bottom label associated with the default route in a particular VRF will introduce the packet to loop up the forwarding entry in corresponding VRF. SPEs would send packets to remote PEs with three layer label stack. SPEs will swap the bottom label to a new bottom label which is assigned by remote PE. The middle label is assigned by the ASBR, which is associated with the /32 route to the remote PE. The top label is assigned by the SPE's IGP Next Hop, corresponding to the /32 route to the ASBR. In HoVPN, since the SPE will only advertise the label binding with the default route for a specific VRF to the UPE, it can greatly reduce the route load and the process burden in the UPE. 4.3.2.2. L2VPN Service stitching- Multi-Segment PW Multi-Segment PW(MS-PW) can stitching two segment PW in one domain together to establish an end-to-en PW across different domains. With MS-PW, it is not necessary to setup LDP remote sessions among the UPEs and the remote PEs. It is just to setup LDP remote session among UPEs and SPEs. Thus it can reduce the load and the process burden proposed by LDP remote sessions. 1. Process of Control Plane o UPEs provide the access service for users. These UPEs act as CSG/ AN to establish LDP remote sessions with SPEs instead of establishing sessions with all remote PEs. o SPEs establish SS-PW(Single-Segment PW) with UPEs and remote PEs and stitching(switch) these two SS-PW together to establish hierarchy PW services across different domains. 2. Process of Forwarding Plane The detail of process of the forwarding plane refers to [I-D.ietf-pwe3-ms-pw-requirements]. Zhenbin Li, et al. Expires August 17, 2014 [Page 17] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 4.4. Reliability 4.4.1. MRT FRR based on LDP MT [I-D.li-rtgwg-ldp-mt-mrt-frr] describes the scenarios of LDP Multi- topology(MT) for unicast fast-reroute using Maximally Redundant Trees(MRT). MRT FRR can provide 100% coverage for fast-reroute of unicast traffic and LDP multi-topology has been proposed to provide multi-topology-based unicast forwarding in the architecture. Combining MRT FRR and LDP MT can be easy to achieve the object of high reliability in IGP/LDP networks. Ring topology has been widely adopted in mobile backhaul networks. The route loop will be bound to happen in the ring network and the existing LFA technology cannot cover the whole network to implement fast reroute functionality. MRT FRR based on LDP MT can be adopted in the mobile backhaul network using LDP to provide 100% coverage for fast-reroute. And the solution can also be deployed uniformly in the core network using LDP to achieve high scalability. 4.5. Policy Control BGP as a route protocol for inter-AS now is used for Seamless MPLS to establish end-to-end hierarchical LSP or deploy VPN services. BGP route policy based on IP-Prefix or communities are usually used to control the path. The design and configuration is complex and error- prone. In fact, BGP in Seamless MPLS is used to propagate labeled BGP routes across different domains to implement network convergence. This means several contiguous BGP networks are under the uniform administration. It is not like the traditional BGP networks which may be under the administration of different service providers. In this cases, thinking on the security of the network can be reduced. On the contrary, when advertise routes in the Seamless MPLS domain, it is desirable for BGP to carry more information to help select routing more intelligently. It can reduce the cost proposed by complex policy control design and be able to adapt to network change easily. 4.6. OAM Mobile Backhaul is a sensitive network on latency timer, packet loss rate, performance and so on. Therefore, unified OAM mechanism is necessary to ensure the end-to-end network management including fault and performance management. OAM mechanisms is complete and mature for L2VPN and MAC services. However, L3VPN are introduced in the mobile backhaul network for better scalability. The OAM mechanisms for IP and L3VPN is not sufficient to satisfy the OAM requirement of the mobile service, Zhenbin Li, et al. Expires August 17, 2014 [Page 18] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 especially for performance monitoring. On the other hand, the Seamless MPLS is in fact composed by multiple contiguous networks. More convenient mechanisms should be introduced for maintenance of the end-to-end path. 4.6.1. L3VPN PM FMC becomes the requirement of mobile backhaul network and L3VPN is introduced to get better scalability for service provisioning. Unlike existing mature OAM mechanism based on PW for L2VPN, L3VPN lacks of similar mechanisms to satisfy the SDH-like OAM requirement for the mobile backhaul service. [I-D.zheng-l3vpn-pm-analysis] analyzes the difficulty to implement performance monitoring for L3VPN owing to its MP2P or MP2MP service models. [I-D.dong-l3vpn-pm-framework] proposes the framework to implement L3VPN PM. The point-to-point connection between two VRFs, called as VRF-to-VRF tunnel, is established. Thus the existing MPLS OAM mechanisms based on P2P LSP models can be reused for L3VPN. 4.6.2. IPFPM (IP Flow Performance Measurement) It is lack of effective performance monitoring mechanisms for IP- based mobile service. The existing PM mechanism can not guarantee that the path of the injected OAM packets is same with the real traffic. If out-of-order arrival of packets happens, the accuracy of the measurement result will be affected negatively for the IP service. [I-D.chen-coloring-based-ipfpm-framework] defines a new performance measurement mechanism for Service Level Agreement (SLA) verification and trouble shooting (e.g., fault localization or fault delimitation) named as IP Flow Performance Measurement (IPFPM). This measurement mechanism can measure performance based on 5-tuple encapsulation information of IP flow without injecting any extra OAM packet to the flow. The accuracy of the measurement result can be guaranteed even if out-of-order arrival of packets happens by setting one unused bit of the IP header of packets to "color" the packets into different color blocks. The solution can adapt to various IP based network architecture (pure IP, L3VPN, etc.) 4.6.3. Service Path Visualization Seamless MPLS provides an architecture to support end-to-end services across multi-separated IP/MPLS domains. Existing path detect technologies (e.g. IP/LSP Ping and Trace) can only trace the path in different layers or different network segments. So it is ineffective to get the end-to-end path combing these technologies for maintenance of the network. On the other hand, existing technologies do not Zhenbin Li, et al. Expires August 17, 2014 [Page 19] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 encapsulate the same 5-tuple {source IP address, destination IP address, source port number, destination port number, IP protocol number} as the real traffic. This means the path maybe be different between the OAM packets and the real flow's packets when there are more than one outgoing paths and the forwarding decision is determined by hash based on 5-tuple information in the IP packet. According to these new requirements, the new solution should be introduced to maintain the end-to-end path more conveniently. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations TBD. 7. Acknowledgements The authors would like to thank Loa Andersson for his valuable comments and suggestions on this draft. The authors would also like to acknowledge the important contributions of Yuanbin Yin on IPFPM and Service Path Visualization. 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. 8.2. Informative References [I-D.chen-coloring-based-ipfpm-framework] Chen, M., Liu, H., and Y. Yin, "Coloring based IP Flow Performance Measurement Framework", draft-chen-coloring- based-ipfpm-framework-01 (work in progress), February 2013. [I-D.dong-l3vpn-pm-framework] Dong, J., Li, Z., and B. Parise, "A Framework for L3VPN Performance Monitoring", draft-dong-l3vpn-pm-framework-02 (work in progress), January 2014. Zhenbin Li, et al. Expires August 17, 2014 [Page 20] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 [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-05 (work in progress), January 2014. [I-D.ietf-pwe3-ms-pw-requirements] Bocci, M. and L. Martini, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", draft-ietf-pwe3 -ms-pw-requirements-07 (work in progress), June 2008. [I-D.li-ccamp-role-based-automesh] Li, Z. and M. Chen, "Routing Extensions for Discovery of Role-based MPLS Label Switching Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership", draft-li-ccamp-role- based-automesh-01 (work in progress), October 2013. [I-D.li-mpls-proxy-te-lsp] Li, Z. and X. Zeng, "Proxy MPLS Traffic Engineering Label Switched Path(LSP)", draft-li-mpls-proxy-te-lsp-00 (work in progress), July 2013. [I-D.li-mpls-serv-driven-co-lsp-fmwk] Li, Z. and J. Dong, "A Framework for Service-Driven Co- Routed MPLS Traffic Engineering LSPs", draft-li-mpls-serv- driven-co-lsp-fmwk-02 (work in progress), January 2014. [I-D.li-ospf-auto-mbb-te-path] Li, Z., Zhang, L., and Y. Liu, "OSPF Extensions for Automatic Computation of MPLS Traffic Engineering Path Using Traffic Engineering Layers and Areas", draft-li- ospf-auto-mbb-te-path-00 (work in progress), February 2013. [I-D.li-rtgwg-ldp-mt-mrt-frr] Li, Z., Chou, T., Zhao, Q., and T. Yang, "Applicability of LDP Multi-Topology for Unicast Fast-reroute Using Maximally Redundant Trees", draft-li-rtgwg-ldp-mt-mrt- frr-02 (work in progress), April 2013. [I-D.zheng-l3vpn-pm-analysis] Zheng, L., Li, Z., Aldrin, S., and B. Parise, "Performance Monitoring Analysis for L3VPN", draft-zheng-l3vpn-pm- analysis-02 (work in progress), October 2013. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. Zhenbin Li, et al. Expires August 17, 2014 [Page 21] Internet-Draft Seamless MPLS for Mobile Backhaul February 2014 [RFC4972] Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, "Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, July 2007. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Lei Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lily.lilei@huawei.com Manuel Julian Lopez Morillo Vodafone Group Networks Parque Empresarial Castellana Norte. Isabel Colbrand 22 Madrid 28050 Spain Email: manuel-julian.lopez@vodafone.com Tianle Yang China Mobile 32, Xuanwumenxi Ave. Beijing 01719 China Email: yangtianle@chinamobile.com Zhenbin Li, et al. Expires August 17, 2014 [Page 22]