Network Working Group Zhenbin Li Internet-Draft Lei Li Intended status: Informational Huawei Technologies Expires: January 4, 2015 Manuel Julian Lopez Morillo Vodafone Group Networks Tianle Yang China Mobile L. Contreras Telefonica I+D July 3, 2014 Seamless MPLS for Mobile Backhaul Network draft-li-mpls-seamless-mpls-mbh-00 Abstract Seamless MPLS architecture is proposed to integrate access and aggregation/core networks into a single MPLS domain. Through the separation of the service and transport plane Seamless MPLS can provide end to end service independent transport. But when the mobile backhaul network is integrated as the access/aggregation network with the core network based on Seamless MPLS architecture, it will proposes new challenges other than the existing solutions for Seamless MPLS. This document introduces the framework of Seamless MPLS to integrate the mobile backhaul network and the core network. The possible challenges of Seamless MPLS for mobile backhaul networks are identified and new requirements are defined accordingly. 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 Zhenbin Li, et al. Expires January 4, 2015 [Page 1] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 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 4, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Mobile Backhaul Network . . . . . . . . . . . . . 4 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Scenarios for Network Architecture . . . . . . . . . . . 6 4.2. Scenarios for Different Edge of Labeled BGP . . . . . . . 8 5. Problem Statements and Requirements . . . . . . . . . . . . . 11 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.1. Problem Statements . . . . . . . . . . . . . . . . . 12 5.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 13 5.3. End-to-End Transport . . . . . . . . . . . . . . . . . . 14 5.3.1. Problem Statement . . . . . . . . . . . . . . . . . . 14 5.3.2. Requirements . . . . . . . . . . . . . . . . . . . . 14 5.4. Hierarchical Service Bearing . . . . . . . . . . . . . . 15 5.4.1. Problem Statements . . . . . . . . . . . . . . . . . 15 5.4.2. Requirements . . . . . . . . . . . . . . . . . . . . 16 5.5. Reliability . . . . . . . . . . . . . . . . . . . . . . . 16 5.5.1. Problem Statements . . . . . . . . . . . . . . . . . 16 5.5.2. Requirements . . . . . . . . . . . . . . . . . . . . 16 5.6. Policy Control . . . . . . . . . . . . . . . . . . . . . 16 5.6.1. Problem Statements . . . . . . . . . . . . . . . . . 16 5.6.2. Requirements . . . . . . . . . . . . . . . . . . . . 17 5.7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.7.1. Problem Statements . . . . . . . . . . . . . . . . . 17 5.7.2. Requirements . . . . . . . . . . . . . . . . . . . . 18 Zhenbin Li, et al. Expires January 4, 2015 [Page 2] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 is the separation of the service and transport plane. Through it Seamless MPLS can provide end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes. 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 based on Seamless MPLS architecture. Though some approaches of the existing Seamless MPLS architecture 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 introduces the framework of Seamless MPLS to integrate the mobile backhaul network and the aggregation/core network. The possible challenges of Seamless MPLS for mobile backhaul networks are identified and new requirements are defined accordingly. The proposed requirements make it possible to work out the complete solution for a flexible deployment of an end to end mobile backhaul service delivery. Currently, this document focuses on end to end unicast service deployment. Multicast is out of scope of the document. 2. Terminology This document uses the following terminology: o ABR: Area Border Router Zhenbin Li, et al. Expires January 4, 2015 [Page 3] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 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 o UPE: Under Provider Edge 3. Overview of Mobile Backhaul Network The typical mobile backhaul network is shown in the Figure 1. It usually adopts ring topology to save fiber resource and it is always divided into the aggregate network and the access network. In the mobile backhaul network, Cell Site Gateways(CSGs) connect the eNodeBs and RNC Site Gateways(RSGs) connect the RNCs. The mobile traffic is transported from CSGs to RSGs. Zhenbin Li, et al. Expires January 4, 2015 [Page 4] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 ---------------- / \ / \ / \ +------+ +----+ Access +----+ |eNodeB|---|CSG1| Ring 1 |ASG1|------------- +------+ +----+ +----+ \ \ / \ \ / +----+ +---+ \ +----+ |RSG1|----|RNC| -------------| | Aggregate +----+ +---+ |ASG2| Ring | -------------| | +----+ +---+ / +----+ |RSG2|----|RNC| / \ +----+ +---+ / \ / +------+ +----+ Access +----+ / |eNodeB|---|CSG2| Ring 2 |ASG3|------------ +------+ +----+ +----+ \ / \ / \ / ----------------- Figure 1 Mobile Backhaul Network Generally RNCs and eNodeBs connects the local mobile backhaul network. In order to utilize the distributed resource, eNodeBs and RNCs may be located in different networks. That is, the mobile service must span multiple networks including the mobile backhaul networks and the core network. In order to facilitate service provision, Seamless MPLS architecture can be introduced to implement the integration of the mobile backhaul networks and the core network. [I-D.ietf-mpls-seamless-mpls] defines the possible requirements and solutions for the integration of the access network and the aggregation/core network into a single MPLS domain. 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. Morevover, devices in existing mobile backhaul networks vary in capacity. So there will be different application scenarios and new challenges when Seamless MPLS architecture is applied for the mobile backhaul network. Note: In order to ease the description, in the following section we will use the PE to represent the CSG in the Seamless MPLS Zhenbin Li, et al. Expires January 4, 2015 [Page 5] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 architecture. In this document the PE and the CSG have the same meaning. 4. 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. 4.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. And the mobile backhaul network including the access network and the aggregation network usually uses a private AS number just for local services. So the integrated end-to-end service means to cross 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 2 Redundant ASBRs connected Back to Back Zhenbin Li, et al. Expires January 4, 2015 [Page 6] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 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 can distribute the PE's /32 route from ASBRs to ingress PEs in targeted 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 3 Integrated ASBRs In this scenario, Seamless MPLS uses label distribution enabled IBGP to establish the end-to-end BGP LSP to support services (that is, it removes the requirement of EBGP sessions) (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). Zhenbin Li, et al. Expires January 4, 2015 [Page 7] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 o The integrated ASBR should support two different ASes and redistribute the labeled IPv4 routes from one AS to neighboring AS. o IBGP can distributes the PE's /32 route from the integrated ASBRs to ingress PEs in targeted AS. 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. In this scenario, the Core network is deployed in a same AS with the access/aggregation network. And the core network, aggregation network and access network are just separated by IGP areas for the reason of scalability. | Service | |----------------------------------------| | AS | |----------------------------------------| | IGP-X | IGP-Y | |(Access/Aggregation)| (Core) | |--------------------|-------------------| | | | +----+ ... |ABR1|.... +----+ ........ +----+ ....... +----+ | PE |... ...| PE | +----+ ..... ..... +----+ ..... +----+ ..... ...|ABR2|.. +----+ Figure 4 Integrated network in one AS In this scenario, Seamless MPLS uses labeled IBGP to establish the end-to-end BGP LSP to support services. 4.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 the 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 will be three possible scenarios. Scenario 1: Cell Site/User PE devices as the edge of labeled BGP Zhenbin Li, et al. Expires January 4, 2015 [Page 8] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 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. | 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 5 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 the access network and BGP LSP in aggregation/core network to support end-to-end services. Zhenbin Li, et al. Expires January 4, 2015 [Page 9] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 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 6 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 January 4, 2015 [Page 10] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 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 7 Labeled BGP ended at ASBRs 5. Problem Statements and Requirements 5.1. Overview Seamless MPLS in [I-D.ietf-mpls-seamless-mpls] describes an architecture by deploying existing protocols like BGP, LDP and ISIS to provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. But more requirements for provision of the mobile service and the specialty of the mobile backhaul network proposes new challenges when Seamless MPLS is applied: 1. Challenges from Ring Network The mobile backhaul network always adopts the ring network deployment. When CSGs access the ring topology and LDP is adopted as the transport plane, there will be multiple hops from CSGs to ASGs/ RSGs which has effect on LDP DoD. Moreover the route loop may always happens which will affect the network coverage of the possible IP FRR/LDP FRR solutions such as LFA [RFC6571] for high reliability. 2. Challenges from MPLS TE In the mobile backhaul network, in order to provide SDH-like service, MPLS TE or MPLS TP technologies are always introduced instead of MPLS LDP for transport of mobile service. When integrate the core network Zhenbin Li, et al. Expires January 4, 2015 [Page 11] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 and the mobile backhaul network, in the transport plane, the interworking between LDP/BGP LSP and RSVP-TE is inevitable. It will have much effect on the end-to-end transport, OAM, protection and scalability. 3. Challenges from L3VPN 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 L2VPN PW. It needs simplification of flexible policy control and providing complete OAM solutions in different layers. 5.2. Scalability 5.2.1. Problem Statements There will be huge configuration when MPLS TE is adopted to transport mobile service. 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. In order to satisfy different requirements of the mobile service, it will propose the configuration issues for MPLS TE: 1. Tunnel/LSP Configuration Since rich set of traffic engineering attributes have to be specified for MPLS TE tunnel and LSP, it has to configure these attributes at the ingress node for each MPLS TE tunnel/LSP to satisfy the requirements such as bandwidth guarantee, fast protection switch, OAM, etc. 2. Path Constraints Configuration In order to satisfy the requirement of path design for MPLS TE LSP, it has to introduce additional configuration which will deteriorate the configuration work for MPLS TE. 1) Return Path Issue of BFD for MPLS LSPs In order for high reliability BFD for MPLS LSPs ([RFC5884]) can be used to detect the possible failure fast which can trigger traffic switch between the primary LSP and the backup LSP of a specific MPLS TE tunnel. When BFD for MPLS LSPs is deployed, the return path of BFD traffic may take an IP path which is different from the forward path. The failure that happens in the return path may cause wrong Zhenbin Li, et al. Expires January 4, 2015 [Page 12] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 traffic switch. In order to solve the return path issue of BFD for MPLS LSPs, it has to be guaranteed that the forward path and the return path must be co-routed. For MPLS TE LSPs the explicit path has to be configured for the forward LSP and the return LSP. 2) Completely disjointed primary and backup LSP MPLS TE Hot-standby feature is always introduced to implement traffic protection. That is, primary LSP and backup LSP are setup at the same time for one MPLS TE tunnel. In order to achieve higher reliability, it is requires that the primary and backup LSP should not share any nodes and links. Thus when failure happens in the primary path, the backup LSP can always take over the traffic. So it has to introduce the additional path constraints configuration to satisfy the requirements. 3) Avoid passing through different access rings When the mobile traffic is transported from the CSG to the RSG, it is expected that the path would not pass through multiple access rings. Since the bandwidth of the access ring is always designed to satisfy its own bandwidth requirement, if mobile traffic from other access ring pass through, the access ring is prone to be overloaded which will cause traffic loss owing to traffic congestion. It is complex to satisfy the requirement using cost, link color or explicit path configurations. In order to cope with above issues, the complex traffic engineering attributes configuration and path constraints configuration has to be introduced for MPLS TE tunnel/LSP. Calculated using the typical MPLS TE tunnel configuration, there will be hundreds of thousands of command lines need to be configured for MPLS TE. Comparing with LDP, the provision work for MPLS TE is time-consuming and error-prone which has much negative effect on the scalability. 5.2.2. Requirements When Seamless MPLS is applied to the mobile backhaul network, in order to solve the configuration issue of MPLS TE to improve scalability, following requirements are proposed: REQ 01: It SHOULD avoid traffic engineering attributes configuration for each MPLS TE tunnel/LSP. Auto tunnel mechanism SHOULD be introduced for provision of MPLS TE tunnel. REQ 02: It SHOULD simplify the path constraints configuration to cope with the return path issue of BFD for MPLS LSPs. Zhenbin Li, et al. Expires January 4, 2015 [Page 13] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 REQ 03: It SHOULD simplify the path constraints configuration to implement completely disjointed primary and backup LSP. REQ 04: It SHOULD simplify the path constraints configuration to avoid traffic passing through different access rings. 5.3. End-to-End Transport 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 the access nodes 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 4.2. This section will introduces new challenges and requirements for MPLS TE and LDP to implement stitching solution for the end-to-end transport. 5.3.1. Problem Statement 1. Proxy Egress MPLS TE LSP In the typical Seamless MPLS architecture, LDP DoD are adopted to setup the segment LSP which is stitched with BGP LSP. When MPLS TE is adopted to deploy in the mobile backhaul network, it is necessary to stitch the MPLS TE LSP set up in the mobile backhaul network and BGP LSP in the core network at the stitching point. Since the actual destination of the MPLS TE LSP may be not located in the local mobile backhaul network, it has to set up the proxy egress MPLS TE LSP from the CSG to the stitching point. 2. Multi-hop LDP DoD In the typical Seamless MPLS architecture, the static route can be configured for set up LDP DoD LSP. In addition, LDP Extension for Inter-Area Label Switched Paths[RFC5283] can be introduced to reduce the numbers of routes. 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 cannot configure the default route for setup of LDP DoD LSP. If static routes are used, it will be troublesome to configure static routes to a specific destination on all nodes in the mobile backhaul network. 5.3.2. Requirements REQ 11: It SHOULD set up MPLS TE proxy egress LSP to stitch with BGP LSP to implement end-to-end transport. Zhenbin Li, et al. Expires January 4, 2015 [Page 14] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 REQ 12: It SHOULD simplify the route configuration to setup multi-hop LDP DoD LSP. 5.4. Hierarchical Service Bearing 5.4.1. Problem Statements Though Seamless MPLS can provide end to end service independent transport and removes the need for service specific configurations in network transport nodes, owing to the limited capability of access nodes it may be necessary to introduce hierarchical MPLS-based service bearing solutions. +----+ +-----+ +-----+ ..|ASG1| ...|ASBR1|-------|ASBR3|.... +----+ .... .+----+. +-----+ +-----+ +----+ | PE |.. ... ...| PE | +----+ .....+----+ . +----+ .|ASG2|. . +-----+ +-----+ .. +----+ ..|ASBR2|-------|ASBR4|.. +-----+ +-----+ | Hierarchy of 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 As shown in the above figure, the access nodes (PEs) may be not able to update to support end to end transport, it can utilize the simple hierarchical MPLS-based service bearing solutions such as Hierarchy of VPN (HoVPN) to stitch two segmented VPNs at the ASG or ASBR to establish a VPN service across different domains. The segmented VPN can simply steer the traffic from the access nodes to the ASG or ASBR with higher capability for complex process. This can also simplify the process of access devices (CSGs) and reduce the capability requirement on lower level network devices. Seamless MPLS is not to stop hierarchical service bearing which may need service specific configurations in network transport nodes. On the contrary, it is to provide more flexibility for MPLS-based service bearing. Depending Zhenbin Li, et al. Expires January 4, 2015 [Page 15] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 on the characteristic of the mobile service, different hierarchical service bearing solutions based on L2VPN or L3VPN should be adopted. 5.4.2. Requirements In order to reduce the requirement on lower level network devices, hierarchical MPLS-based service bearing solutions can be introduced for mobile service. Following requirements are proposed: REQ 31: Hierarchical L3VPN solutions MAY be introduced to bear L3-based mobile service. REQ 32: Hierarchical L2VPN solutions MAY be introduced to bear L2-based mobile service. 5.5. Reliability 5.5.1. Problem Statements The ring topology is always adopted in the mobile backhaul network. The route loop will be bound to happen in the ring network when LFA solution is applied. This means that the backup route does not exist in specific nodes of the ring network according to LFA. Regarding Remote LFA FRR [I-D.ietf-rtgwg-remote-lfa], though it can improve the network coverage comparing with LFA, it still faces the route loop challenges for the back path. In addition, when R-LFA is adopted, there has to set up LDP remote sessions which will propose the scalability issue for fast protection. 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. 5.5.2. Requirements REQ 41: Scalable IP/LDP FRR solutions SHOULD be provided for the purpose of 100% network coverage when LDP is used for transport of mobile service. 5.6. Policy Control 5.6.1. Problem Statements 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. Zhenbin Li, et al. Expires January 4, 2015 [Page 16] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 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 case, consideration 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. 5.6.2. Requirements REQ 51: BGP SHOULD be able to carry more information to facilitate the route policy control. 5.7. OAM 5.7.1. Problem Statements 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 management and performance monitoring. 1. Layering OAM Framework for L3VPN Service When VPN is used to bear mobile service, multiple layers come into play for implementing the VPN service. This layering extends to the set of OAM protocols that are involved in the ongoing maintenance and diagnostics of VPN networks. The figure below depicts the OAM layering, and shows which devices have visibility into what OAM layer(s). +---+ +---+ +--+ | | +---+ +---+ +---+ | | +--+ |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| +--+ | | +---+ +---+ +---+ | | +--+ +---+ +---+ o--------o--------- Service OAM -------------o--------o o----------- Network OAM -----------o o-------o--------o---------o-------o Transport OAM o-----o o-----o o-----o o-----o o-----o o-----o Link OAM Figure 9 VPN OAM Layering Zhenbin Li, et al. Expires January 4, 2015 [Page 17] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 OAM mechanisms is relatively complete and mature for L2VPN services. However, L3VPN are introduced in the mobile backhaul network for better scalability. The multiple layers for an L3VPN service are as follows: - The Service Layer runs end to end between the sites that are being interconnected by the L3VPN solution. It is always IP network. - The Network Layer extends in between the L3VPN PE nodes and is mostly transparent to the core nodes (except where Flow Entropy comes into play). It leverages MPLS for service (i.e. VRF) multiplexing. - The Transport Layer is dictated by the networking technology of the PSN. It may be either based on MPLS LSPs or IP. - The Link Layer is dependent upon the physical technology used. Ethernet is a popular choice for this layer, but other alternatives are deployed (e.g. POS, DWDM etc...). The existing OAM mechanisms for IP and L3VPN is not sufficient to satisfy the OAM requirement of the mobile service, especially for performance monitoring. 2. Flat End-to-End OAM Mechanism Seamless MPLS provides an architecture to support end-to-end services across multi-separated IP/MPLS domains. Existing path detection 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 for maintenance of the network. On the other hand, existing technologies do not 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.7.2. Requirements REQ 61: Performance monitoring mechanism SHOULD be provided for the IP flow. REQ 62: Performance monitoring mechanism SHOULD be provided for the VPN flow between a pair of L3VPN members. Zhenbin Li, et al. Expires January 4, 2015 [Page 18] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 REQ 63: The end-to-end path trace mechanism SHOULD be provided for the IP flow to collect the whole path information in multiple layers. 6. IANA Considerations This document makes no request of IANA. 7. Security Considerations TBD. 8. 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. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 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.ietf-rtgwg-remote-lfa] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06 (work in progress), May 2014. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. Zhenbin Li, et al. Expires January 4, 2015 [Page 19] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", RFC 6571, June 2012. 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 January 4, 2015 [Page 20] Internet-Draft Seamless MPLS for Mobile Backhaul Network July 2014 Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://people.tid.es/LuisM.Contreras/ Zhenbin Li, et al. Expires January 4, 2015 [Page 21]