Internet Engineering Task Force Lianyuan. Li Internet-Draft Lu. Huang Intended status: Standards Track China Mobile, Inc. Expires: September 15, 2011 N. So Verison Business A. Kvalbein Resiliens Communication AS March 14, 2011 MPLS Multiple Topology Applicability and Requirements draft-li-mpls-mt-applicability-requirement-01.txt Abstract This document describes the applicability and requirements for Multiprotocol Label Switching Multiple Topology (MPLS-MT). The applicability and requirements are presented from different angles. They are expressed from a customer's point of view, a service provider's point of view and a vendor's point of view. Status of this Memo This Internet-Draft is submitted to IETF 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 September 15, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Li, et al. Expires September 15, 2011 [Page 1] Internet-Draft MPLS MT March 2011 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 6 3.2. Automation of inter-layer interworking . . . . . . . . . . 7 3.3. Migration without service disruption . . . . . . . . . . . 7 3.4. Protection using MT . . . . . . . . . . . . . . . . . . . 8 3.5. Service Separation . . . . . . . . . . . . . . . . . . . . 8 3.6. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Inter-domain MPLS-TE and MPLS VPN . . . . . . . . . . . . 9 4. Service requirements . . . . . . . . . . . . . . . . . . . . . 9 4.1. Availability . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Physical Diversity and FRR . . . . . . . . . . . . . . 9 4.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Data isolation . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.1. User data security . . . . . . . . . . . . . . . . . . 11 4.5.2. Access control . . . . . . . . . . . . . . . . . . . . 11 4.5.3. MT router authentication and authorization . . . . . . 11 4.5.4. Inter domain security . . . . . . . . . . . . . . . . 11 4.6. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 12 4.8. Quality of Service . . . . . . . . . . . . . . . . . . . . 12 4.9. Network Resource Partitioning and Sharing between MPLS-MTs (REWRITE with emphasis/focus on partition) . . . 12 5. Provider requirements . . . . . . . . . . . . . . . . . . . . 13 5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Service Provider Capacity Sizing Projections . . . . . 13 5.1.2. MPLS-MT Scalability aspects . . . . . . . . . . . . . 14 5.1.3. Number of MPLS-MTs in the network . . . . . . . . . . 14 5.1.4. Number of MPLS-MTs per customer . . . . . . . . . . . 14 5.1.5. Number of addresses and address prefixes per MPLS-MT . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.6. Solution-Specific Metrics . . . . . . . . . . . . . . 15 5.2. Management . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Customer Management of a MPLS-MT . . . . . . . . . . . . . 15 6. Engineering requirements . . . . . . . . . . . . . . . . . . . 16 6.1. Forwarding plane requirements . . . . . . . . . . . . . . 16 6.2. Control plane requirements . . . . . . . . . . . . . . . . 16 Li, et al. Expires September 15, 2011 [Page 2] Internet-Draft MPLS MT March 2011 6.3. Control Plane Containment . . . . . . . . . . . . . . . . 16 6.4. Requirements for commonality of MPLS-MT mechanisms . . . . 17 6.5. Interoperability . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Li, et al. Expires September 15, 2011 [Page 3] Internet-Draft MPLS MT March 2011 1. Terminology Terminology used in this document Non-MT: router Routers that do not have the MT capability. MT router: Routers that have MT capability as described in this document. MT-ID: Renamed TOS field in LSAs to represent Multi-Topology ID. Default topology: Topology that is built using the TOS 0 metric (default metric). MT topology: Topology that is built using the corresponding MT-ID metric. MT: Shorthand notation for MPLS Virtual Topology. MT#0 topology: Representation of TOS 0 metric in MT-ID format. Non-MT-Area: An area that contains only non-MT routers. MT-Area: An area that contains both non-MT routers and MT routers, or only MT routers. 2. Introduction "Multi-Topology Routing in OSPF", RFC4915, describes a mechanism for Open Shortest Path First protocol to support Multi-Topologies (MTs) in IP network where the Type of Service (TOS) based metric fields are redefined and are used to advertise different topologies, each with a separate link metric. The classification of what type of traffic maps to which topology is not defined in RFC4915. The interface can be configured to belong to a set of topologies. Network topology changes will be advertised independently for each topology using a Multi-Topology Identifier (MT-ID), so that IP packets can be forwarded in the specific network topology independently. "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC5120, describes a mechanism within Intermediate System to Intermediate Systems (IS-ISs) to run a set of independent IP topologies. The existing IS-IS protocol is extended so that the formation of adjacencies and advertising of prefixes and reachable intermediate system are performed independently within each topology. Li, et al. Expires September 15, 2011 [Page 4] Internet-Draft MPLS MT March 2011 There is a need to support Multiple-Topologies in MPLS network where a label switch path (LSP) is established within one topology or across multiple topologies and the traffic can be forwarded along the LSP within each network topology or across multiple topologies. This document presents requirements for Multiprotocol Label Switching Multiple-Topology (MPLS-MT). It identifies requirements that may apply to one or more individual approaches that a Service Provider may use to provision LSPs in MPLS-MT. The specification of technical means to provide MPLS-MT services is outside the scope of this document. Other documents are intended to cover this aspect. This document is intended as a "checklist" of requirements, providing a consistent way to evaluate and document how well each approach satisfies specific requirements. The applicability statement documents for each approach should provide the results of this evaluation. This document is not intended to compare one approach to another. This document presents requirements from several points of view. It begins with some considerations from a point of view common to customers and service providers, continues with a customer perspective, and concludes with specific needs of a Service Provider (SP). There are three different deployment scenarios MPLS-MT services are considered in this document: 1. Single-provider, single-AS: This is the least complex scenario, where the MPLS-MT service is offered across a single service provider network spanning a single Autonomous System. 2. Single-provider, multi-AS: In this scenario, a single provider may have multiple Autonomous Systems (e.g., a global Tier-1 ISP with different ASes depending on the global location, or an ISP that has been created by mergers and acquisitions of multiple networks). This scenario involves the constrained distribution of routing information across multiple Autonomous Systems. 3. Multi-provider: This scenario is the most complex, wherein trust negotiations need to be made across multiple service provider backbones in order to meet the security and service level agreements for the MPLS-MT customer. This scenario can be generalized to cover the Internet, which comprises of multiple service provider networks. It should be noted that customers can construct their own MPLS-MTs across multiple providers. However such MPLS-MTs are not considered here as they would not be "Providerprovisioned". MPLS-MT is set of extensions to existing MPLS signaling protocols that makes MPLS signaling protocols aware of multi-topology. In the context of MPLS signaling the term "Multi-topology" is redefined to Li, et al. Expires September 15, 2011 [Page 5] Internet-Draft MPLS MT March 2011 be protocol independent unlike IGP-MT, which is scoped inside a single flavor IGP (ex. ISIS-MT or OSPF-MT). In other words, a MPLS Multiple-Topologycan be mapped to a OSPFv2 based topology, OSPFv3 based topology or ISIS based IGP topology. Besides, a MPLS multi- topology can also be mapped to an instance of OSPF-MT or ISIS-MT. There are two major categories for MPLS-MT applications: a) MPLS RSVP-TE-MT applications, b) MPLS LDP-MT applications. The following sections of the draft describe application scenarios and MPLS-MT signaling in general. These application scenarios are useful for service providers who already have an MPLS network, or for service providers willing to migrate from IP to MPLS. The following Sections describe applicability and generic MPLS-MT requirements. 3. Applicability There are two main scenarios for how MPLS-MT can be used as a value- adding tool: 1) It can be exposed to and used by the customer to suit particular needs. For example, a customer might be given the option to select from a range of different topologies with different price and quality characteristics, and can select one (or more) that fulfils the given requirements. This could allow a service provider to better exploit network resources, by using pricing as an incentive. 2) It can be used as a management tool by the network operator to achieve certain goals such as resilience, traffic isolation and congestion avoidance, without exposing this to customers. Of course, one scenario does not exclude the other: an operator might want to offer MT routing to large customers, while also using it as a tool for "internal" purposes for its best effort services. 3.1. Simplified Data-plane IGP-MT requires additional data-plane resources to maintain a separate forwarding table for each configured MT. On the other hand, MPLS-MT does not change the data-plane system architecture, if an IGP-MT is mapped to an MPLS-MT. In case MPLS-MT, the incoming label value itself can determine an MT, and hence it requires a single NHLFE space. MPLS-MT requires only MT-RIBs in the control-plane, and there is no need to have extra MT-FIBs. Forwarding IP packets over a particular MT requires either configuration or some external means at every node, to map an attribute of incoming IP packet header to IGP-MT, which is additional overhead for network management. With MPLS-MT, mapping is required only at the ingress-PE of an MPLS-MT LSP, because each node identifies MPLS-MT LSP switching based on incoming label, hence no additional configuration is required at Li, et al. Expires September 15, 2011 [Page 6] Internet-Draft MPLS MT March 2011 every node. 3.2. Automation of inter-layer interworking With (G)MPLS-RSVP-MT extensions, an ingress-PE can signal a particular path (ERO) that can traverse different network layers to reach a egress-PE. For instance, an ERO is associated with MT-ID RSVP subobject to indicate a "P" router to use a particular Layer-1 TE- link-state topology, instead of the default Layer-3 link-state topology as illustrated in the following diagram. With this mechanism a (G)MPLS-TE LSP can be offloaded to lower layers without service disruption and without complexity of configuration. +-------+ +-------+ +---------+ R3 .__________ | R4 +------. | +-------+ +-------+ | +-------+ +--+---+ +-'---+ | I-PE |_.| P | |E-PE | | | +--+---+ +-.---+ +-------+ | | | +---------+ +-------+ | |_______| S1 |_____| S2 |____________| +---------+ +-------+ Figure 1: Layer-3 Link State Topology Layer-3 ERO : P[MT-0]->R3->R4->E-PE[MT-0]. Inter-layer ERO : P[MT-0]->loose-hop[MT-1]->E-PE[MT-0] Procedures to discover MT mapping with an IGP topology at ingress-PE nodes requires some auto-discovery mechanism. Figure 1: Layer-3 Link State Topology 3.3. Migration without service disruption As stated above, MPLS-MT abstracts link state topology and identifies it by a unique MT-ID, which need not be the same as the IGP-MT ID. This characteristic is quite useful for service providers looking to migrate to a different flavor of IGP, e.g., OSPFv2 to ISIS6, OSPFv2 to OSPFv3. Service providers would like to incrementally upgrade their topologies, which requires an LSP to traverse multiple IGP Li, et al. Expires September 15, 2011 [Page 7] Internet-Draft MPLS MT March 2011 domains (OSPFv2 to OSPFv3) or (OSPF to ISIS). Migrating TE-LSPs to use a newly deployed link state topology requires a non-trivial effort. This migration may involve service disruption, especially when a path includes loose-hops in the ERO. For example: When an incoming PATH message requires an LSR to resolve loose-hop over a newly deployed IGP domain, which is not possible in the absence of MPLS-MT signaling. MPLS-MT allows an ingress-PE to specify Multiple- Topology to be used at every hop. 3.4. Protection using MT We know that [IP-FRR-MT] can be used for configuring alternate paths via backup-mt, such that if the primary link fails, then a backup-MT can be used for forwarding. However, such techniques require special marking of IP packets that are forwarded using backup-MTs. MPLS-LDP-MT procedures simplify the forwarding of the MPLS packets over backup-MTs, as the MPLS-LDP-MT procedure distributes separate labels for each MT. How backup paths are computed depends on the implementation, and the algorithm. MPLS-RSVP-MT in conjunction with IGP-MT could be used to separate the primary traffic and backup traffic. For example, service providers can create a backup MT that consists of links that are meant only for backup traffic. Service providers can then establish bypass LSPs, standby LSPs, using backup MT, thus keeping undeterministic backup traffic away from the primary traffic. Another case is for mLDP. Since mLDP is based on IGP, in a same topology(or AS), when a backup mLDP is construct, it is diffult for the backup mLDP to find physical links different from those in the primary mLDP. With MPLS MT, the primary mLDP and backup mLDP can be construct in different topology with differnt links. So it is quite easy to set up primary and secondary mLDP with differnt links. 3.5. Service Separation MPLS-MT procedures allow establishing two distinct LSPs for the same FEC, by advertising a separate label mapping for each configured topology. Service providers can implement CoS using MPLS-MT procedures without requiring to create a separate FEC address for each class. MPLS-MT can also be used to separate multicast and unicast traffic. 3.6. Load Balancing MPLS-MT can be used to construct several alternative LSPs between PE routers. The LSPs in different topologies might follow partly overlapping routes through the network, or be completely disjoint. By smart assignment traffic to different MTs at the PE routers, it is Li, et al. Expires September 15, 2011 [Page 8] Internet-Draft MPLS MT March 2011 possible to offload traffic from heavily loaded links, and hence reduce the risk of congestion and improve resource utilization. This type of load balancing can be performed either in an offline way, where traffic is assigned to each MT according to a static split ratio, or in an online fashion, where the amount of traffic assigned to each MT according to a dynamic splitting function that depends on the current load situation. 3.7. Inter-domain MPLS-TE and MPLS VPN Without MPLS MT, when a MPLS-TE tunnel is to be construct across multiple AS, PCE function has to be supported in each router in the MPLS-TE tunnel. With MPLS MT, routers in different ASs can be included into a new AS. In this way, MPLS-TE tunnels can be easily set up. MPLS VPNs can be constructed across differnet ASs. In some case, when there are multiple ASs, it is quite difficult to manage the inter-as MPLS VPN. With MPLS MT, all the PEs can be configured in a singe AS, so the MPLS VPN can be constructed and managed easily. 4. Service requirements These are the requirements that a customer can observe or measure for verifying whether the MPLS-MT service that the Service Provider (SP) provides is satisfactory. As mentioned before, each of these requirements apply equally across each of the three deployment scenarios unless stated otherwise. 4.1. Availability MPLS-MT services MUST have high availability. LSPs that cross over several MTs require connectivity to be maintained even in the event of network failures. This can be achieved via various redundancy techniques such as: 4.1.1. Physical Diversity and FRR A single MT router may be connected to multiple MT routers. For a LSP, both local protections and global protections can be set up. Thus when a network failure happens, the traffic carried by the LSP can continue to flow across the MTs from the head end of the LSP to the tail ends of the LSP. It should be noted that it is difficult to guarantee high availability when the MPLS-MT service is across multiple providers, Li, et al. Expires September 15, 2011 [Page 9] Internet-Draft MPLS MT March 2011 unless there is a negotiation between the different service providers to maintain the service level agreement for the MPLS-MT customer. 4.2. Stability In addition to availability, MPLS-MT services MUST also be stable. Stability is a function of several components such as MT routing and MPLS-MT signaling. For example, in the case of MT routing, route flapping or routing loops MUST be avoided in order to ensure stability. Stability of the MPLS-MT service is directly related to the stability of the mechanisms and protocols used to establish LSPs. It SHOULD also be possible to allow network upgrades and maintenance procedures without impacting the MPLS-MT service. 4.3. Traffic types MPLS-MT services MUST support unicast (or point to point) traffic and SHOULD support multicast (or point-to-multipoint) traffic. For multicast traffic, the network delivers a stream to a set of destinations that have registered interest in the stream through a P2MP LSP. It is desirable to support multicast limited in scope to an intranet or extranet. The solution SHOULD be able to support a large number of such intranet or extranet specific multicast groups in a scalable manner. All MPLS-MT approaches SHALL support both IPv4 and IPv6 traffic. 4.4. Data isolation The MPLS-MT MUST support forwarding plane isolation. The network MUST never deliver user data across MPLS-MT boundaries unless the two MPLS-MTs participate in an intranet or extranet. Furthermore, if the provider network receives signaling or routing information from one MPLS-MT, it MUST NOT reveal that information to another MPLS-MT unless the two MPLS-MTs participate in an intranet or extranet. It should be noted that the disclosure of any signaling/ routing information across an extranet MUST be filtered per the extranet agreement between the organizations participating in the extranet. 4.5. Security A range of security features SHOULD be supported by the suite of MPLS-MT solutions in the form of securing customer flows, providing authentication services for temporary, remote or mobile users, and the need to protect service provider resources involved in supporting a MPLS-MT. Each MPLS-MT solution SHOULD state which security features it supports and how such features can be configured on a per Li, et al. Expires September 15, 2011 [Page 10] Internet-Draft MPLS MT March 2011 customer basis. Protection against Denial of Service (DoS) attacks is a key component of security mechanisms. Some security mechanisms may be equally useful regardless of the scope of the MPLS-MT. Other mechanisms may be more applicable in some scopes than in others. For example, in some cases of single -provider single-AS MPLS-MTs, the MPLS-MT service may be isolated from some forms of attack by isolating the infrastructure used for supporting MPLS-MTs from the infrastructure used for other services. However, the requirements for security are common regardless of the scope of the MPLS-MT service. 4.5.1. User data security MPLS-MT solutions that support user data security SHOULD use standard methods to achieve confidentiality, integrity, authentication and replay attack prevention. Such security methods MUST be configurable between different end points. It is also desirable to configure security on a per-LSP basis. User data security using encryption is especially desirable in the multi-provider scenario. 4.5.2. Access control A MPLS-MT solution may also have the ability to activate the appropriate filtering capabilities upon request of a customer. A filter provides a mechanism so that access control can be invoked at the point(s) of communication between different organizations involved in an extranet. Access control can be implemented by a firewall, access control lists on routers, cryptographic mechanisms or similar mechanisms to apply policy-based access control. Such access control mechanisms are desirable in the multi-provider scenario. 4.5.3. MT router authentication and authorization A MPLS-MT solution requires authentication and authorization of the following: 1. temporary and permanent access for users connecting to a MT router (authentication and authorization BY the MT router) 2. the MT router itself (authentication and authorization FOR the MT router) 4.5.4. Inter domain security The MPLS-MT solution MUST have appropriate security mechanisms to prevent the different kinds of Distributed Denial of Service (DDoS) Li, et al. Expires September 15, 2011 [Page 11] Internet-Draft MPLS MT March 2011 attacks, misconfiguration or unauthorized accesses in inter domain MPLS-MT connections. This is particularly important for multiservice provider deployment scenarios. However, this will also be important in single-provider multi-AS scenarios. 4.6. Topology An MPLS-MT implementation SHOULD support arbitrary, customer -defined connectivity to the extent possible, for example, from partial mesh to full mesh topology. These can actually be different from the topology used by the service provider. The MPLS-MT services SHOULD be independent of MPLS-MT technology. To the extent possible, a MPLS-MT service SHOULD be independent of the geographic extent of the deployment. Multiple MPLS-MTs per customer SHOULD be supported without requiring additional hardware resources. 4.7. Addressing Each customer resource MUST be identified by an address that is unique within its MPLS-MT. It need not be identified by a globally unique address. Support for private addresses as described in [RFC1918], as well as overlapping customer addresses SHALL be supported. One or more MPLS-MTs for each customer can be built over the same infrastructure without requiring any of them to renumber. The solution MUST NOT use NAT on the customer traffic to achieve that goal. Interconnection of two networks with overlapping IP addresses is outside the scope of this document. 4.8. Quality of Service A technical approach for supporting MPLS-MTs SHALL be able to support QoS via IETF standardized mechanisms such as Diffserv. Support for best-effort traffic SHALL be mandatory for all MPLS-MT types. The extent to which any specific MPLS-MT service will support QoS is up to the service provider. In many cases single -provider single-AS MPLS-MTs will offer QoS guarantees. Support of QoS guarantees in the multiservice- provider case will require cooperation between the various service providers involved in offering the service. 4.9. Network Resource Partitioning and Sharing between MPLS-MTs (REWRITE with emphasis/focus on partition) Network resources such as memory space, FIB table, bandwidth and CPU processing SHALL be shared between MPLS-MTs and, where applicable, with non-MPLS-MT Internet traffic. Mechanisms SHOULD be provided to prevent any specific MPLS-MT from taking up available network resources and causing others to fail. SLAs to this effect SHOULD be provided to the customer. Similarly, resources used for control Li, et al. Expires September 15, 2011 [Page 12] Internet-Draft MPLS MT March 2011 plane mechanisms are also shared. When the service provider's control plane is used to distribute MPLS -MT specific information and provide other control mechanisms for MPLS-MTs, there SHALL be mechanisms to ensure that control plane performance is not degraded below acceptable limits when scaling the MPLS-MT service, or during network events such as failure, routing instabilities etc. Since a service provider's network would also be used to provide Internet service, in addition to MPLS-MTs, mechanisms to ensure the stable operation of Internet services and other MPLS-MTs SHALL be made in order to avoid adverse effects of resource hogging by large MPLS-MT customers. 5. Provider requirements This section describes operational requirements for a cost -effective, profitable MPLS-MT service offering. 5.1. Scalability The scalability for MPLS-MT solutions has many aspects. The list below is intended to comprise of the aspects that MPLS-MT solutions SHOULD address. Clearly these aspects in absolute figures are very different for different types of MPLS -MTs. It is also important to verify that MPLS-MT solutions not only scales on the high end, but also on the low end - i.e., a MPLS-MT with three nodes and three users should be as viable as a MPLS-MT with hundreds of nodes and thousands of users. 5.1.1. Service Provider Capacity Sizing Projections A MPLS-MT solution SHOULD be scalable to support a large number of MPLS-MTs per Service Provider network. A MPLS-MT solution SHOULD be scalable to support of a large number of routes per MPLS-MT. The number of routes per MPLS-MT may range from just a few to (O(10^5)) exchanged between ISPs, with typical values being in the O(10^3) range. The high end number is especially true considering the fact that many large ISPs may provide MPLS-MT services to smaller ISPs or large corporations. A MPLS-MT solution SHOULD support high values of the frequency of configuration setup and change. Approaches SHOULD articulate scaling and performance limits for more complex deployment scenarios, such as single-provider multi-AS MPLS-MTs, multi -provider MPLS-MTs. Approaches SHOULD also describe other dimensions of interest, such as capacity requirements or limits, number of interworking instances supported as well as any scalability implications on management Li, et al. Expires September 15, 2011 [Page 13] Internet-Draft MPLS MT March 2011 systems. A MPLS-MT solution SHOULD support a large number of customer interfaces on a single PE or CE with current Internet protocols. 5.1.2. MPLS-MT Scalability aspects This section describes the metrics for scaling MPLS-MT solutions. These numbers are only representative and different service providers may have different requirements for scaling. Further discussion on service provider sizing projections is in Section 5.1.1. It should also be noted that the numbers given below would be different depending on whether the scope of the MPLS-MT is single-provider single-AS, single-provider multi-AS, or multiprovider. Clearly, the larger the scope, the larger the numbers that may need to be supported. However, this also means more management issues. The numbers below may be treated as representative of the single-provider case. 5.1.3. Number of MPLS-MTs in the network The number of MPLS-MTs SHOULD scale linearly with the size of the access network and with the number of PEs. The number of MPLS-MTs in the network SHOULD be O(10). This requirement also effectively places a requirement on the number of tunnels that SHOULD be supported in the network. 5.1.4. Number of MPLS-MTs per customer In some cases a service provider may support multiple MPLS-MTs for the same customer of that service provider. For example, this may occur due to differences in services offered per MPLS-MT (e.g., different QoS, security levels, or reachability) as well as due to the presence of multiple workgroups per customer. It is possible that one customer will run up to O(10) MPLS-MTs. 5.1.5. Number of addresses and address prefixes per MPLS-MT Since any MPLS-MT solution SHALL support private customer addresses, the number of addresses and address prefixes are important in evaluating the scaling requirements. The number of address prefixes used in routing protocols and in forwarding tables specific to the MPLS-MT needs to scale from very few (for smaller customers) to very large numbers seen in typical Service Provider backbones. The high end is especially true considering that many Tier 1 SPs may provide MPLS-MT services to Tier 2 SPs or to large corporations. This number would be on the order of addresses supported in typical native backbones. Li, et al. Expires September 15, 2011 [Page 14] Internet-Draft MPLS MT March 2011 5.1.6. Solution-Specific Metrics Each MPLS-MT solution SHALL document its scalability characteristics in quantitative terms. A MPLS-MT solution SHOULD quantify the amount of state that a PE and P device has to support. This SHOULD be stated in terms of the order of magnitude of the number of MPLS-MTs supported by the service provider. 5.2. Management A service provider MUST have a means to view the topology, operational state, service order status, and other parameters associated with each customer's MPLS-MT. Furthermore, the service provider MUST have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the MPLS -MT service(s) to its customers. In the multi-provider scenario, it is unlikely that participating providers would provide each other a view to the network topology and other parameters mentioned above. However, each provider MUST ensure via management of their own networks that the overall MPLS -MT service offered to the customers are properly managed. In general the support of a single MPLS-MT spanning multiple service providers requires close cooperation between the service providers. One aspect of this cooperation involves agreement on what information about the MPLS-MT will be visible across providers, and what network management protocols will be used between providers. MPLS-MT devices SHOULD provide standards-based management interfaces wherever feasible. 5.3. Customer Management of a MPLS-MT A customer SHOULD have a means to view the topology, operational state, service order status, and other parameters associated with his or her MPLS-MT. A customer SHOULD be able to make dynamic requests for changes to traffic parameters. A customer SHOULD be able to receive real-time response from the SP network in response to these requests. One example of such service is a "Dynamic Bandwidth management" capability, that enables real-time response to customer requests for changes of allocated bandwidth allocated to their MPLS-MT(s). A possible outcome of giving customers such capabilities is Denial of Service attacks on other MPLS-MT customers or Internet users. This possibility is documented in the Security Considerations section. Li, et al. Expires September 15, 2011 [Page 15] Internet-Draft MPLS MT March 2011 6. Engineering requirements These requirements are driven by implementation characteristics that make service and provider requirements achievable. 6.1. Forwarding plane requirements The SP is REQUIRED to provide per-MPLS-MT management, tunnel maintenance and other maintenance required in order to meet the SLA/ SLS. By definition, MPLS-MT traffic SHOULD be segregated from each other, and from non-MPLS-MT traffic in the network. After all, MPLS-MTs are a means of dividing a physical network into several logical or physical networks. MPLS-MT traffic separation SHOULD be done in a scalable fashion. However, safeguards SHOULD be made available against misbehaving MPLS-MTs to not affect the network and other MPLS-MTs. A MPLS-MT solution SHOULD NOT impose any hard limit on the number of MPLS-MTs provided in the network. 6.2. Control plane requirements The plug and play feature of a MPLS-MT solution with minimum configuration requirements is an important consideration. The MPLS-MT solutions SHOULD have mechanisms for protection against customer interface and/or routing instabilities so that they do not impact other customers' services or impact general Internet traffic handling in any way. A MPLS-MT SHOULD be provisioned with minimum number of steps. For this to be accomplished, an auto-configuration and an auto-discovery protocol, which SHOULD be as common as possible to all MPLS-MT solutions, SHOULD be defined. However, these mechanisms SHOULD NOT adversely affect the cost, scalability or stability of a service by being overly complex, or by increasing layers in the protocol stack. Mechanisms to protect the SP network from effects of misconfiguration of MPLS-MTs SHOULD be provided. This is especially of importance in the multi-provider case, where misconfiguration could possibly impact more than one network. 6.3. Control Plane Containment The MPLS-MT control plane MUST include a mechanism through which the service provider can filter MPLS-MT related control plane information as it passes between Autonomous Systems. For example, if a service Li, et al. Expires September 15, 2011 [Page 16] Internet-Draft MPLS MT March 2011 provider supports a MPLS-MT offering, but the service provider's neighbors do not participate in that offering, the service provider SHOULD NOT leak MPLS-MT control information into neighboring networks. Neighboring networks MUST be equipped with mechanisms that filter this information should the service provider leak it. This is important in the case of multi-provider MPLS-MTs as well as singleprovider multi-AS MPLS-MTs. 6.4. Requirements for commonality of MPLS-MT mechanisms The mechanisms used to establish a MPLS-MT service SHOULD re-use well-known IETF protocols as much as possible. It should, however, be noted that the use of Internet mechanisms for the establishment and running of an Internet-based MPLS-MT service, SHALL NOT affect the stability, robustness, and scalability of the Internet or Internet services. In other words, these mechanisms SHOULD NOT conflict with the architectural principles of the Internet, nor SHOULD it put at risk the existing Internet systems. In addition to commonality with generic Internet mechanisms, infrastructure mechanisms used in different MPLS-MT solutions SHOULD be as common as possible. 6.5. Interoperability Each technical solution is expected to be based on interoperable Internet standards. Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution SHOULD be ensured (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers. The technical solution MUST be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the MPLS-MT service. Inter-domain interoperability - It SHOULD be possible to deploy a MPLS-MT solution across domains, Autonomous Systems, or the Internet. 7. IANA Considerations TBD Li, et al. Expires September 15, 2011 [Page 17] Internet-Draft MPLS MT March 2011 8. Acknowledgement Thanks for the contributions from Quintin Zhao, Ravi Tori, Huaimo Chen, Luyuang Fang, Chao Zhou. 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. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [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. [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. 9.2. Informative References Authors' Addresses L Li China Mobile, Inc. 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China Email: lilianyuan@chinamobile.com Li, et al. Expires September 15, 2011 [Page 18] Internet-Draft MPLS MT March 2011 L Huang China Mobile, Inc. 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China Email: huanglu@chinamobile.com Ning So Verison Business 2400 North Glenville Drive Richardson, TX 78052 USA Email: Ning.So@verizonbusiness.com Amund Kvalbein Resiliens Communication AS Martin Linges v 17, Fornebu Fornebu, Lysaker 1325 Norway Email: Amundk@simula.com Li, et al. Expires September 15, 2011 [Page 19]