Internet Engineering Task Force L. Li
Internet-Draft L. Huang
Intended status: Standards Track China Mobile, Inc.
Expires: April 21, 2011 N. So
Verison Business
A. Kvalbein
Resiliens Communication AS
October 18, 2010
MPLS Multiple Topology Applicability and Requirements
draft-li-mpls-mt-applicability-requirement-00.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 April 21, 2011.
Copyright Notice
Copyright (c) 2010 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 April 21, 2011 [Page 1]
Internet-Draft MPLS MT October 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 5
3.2. Automation of inter-layer interworking . . . . . . . . . . 6
3.3. Migration without service disruption . . . . . . . . . . . 6
3.4. Protection using MT . . . . . . . . . . . . . . . . . . . 7
3.5. Service Separation . . . . . . . . . . . . . . . . . . . . 7
3.6. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Service Requirements . . . . . . . . . . . . . . . . . . . 8
4.1.1. Availability . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Stability . . . . . . . . . . . . . . . . . . . . . . 8
4.1.3. Traffic types . . . . . . . . . . . . . . . . . . . . 8
4.1.4. Data isolation . . . . . . . . . . . . . . . . . . . . 9
4.1.5. Security . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.6. Topology . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.7. Addressing . . . . . . . . . . . . . . . . . . . . . . 10
4.1.8. Quality of Service . . . . . . . . . . . . . . . . . . 11
4.1.9. Network Resource Partitioning and Sharing between
MPLS-MTs (REWRITE with emphasis/focus on
partition) . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Provider requirements . . . . . . . . . . . . . . . . . . 11
4.2.1. Scalability . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. Management . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Customer Management of a MPLS-MT . . . . . . . . . . . 14
4.3. Engineering requirements . . . . . . . . . . . . . . . . . 14
4.3.1. Forwarding plane requirements . . . . . . . . . . . . 14
4.3.2. Control plane requirements . . . . . . . . . . . . . . 15
4.3.3. Control Plane Containment . . . . . . . . . . . . . . 15
4.3.4. Requirements for commonality of MPLS-MT mechanisms . . 15
4.3.5. Interoperability . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Li, et al. Expires April 21, 2011 [Page 2]
Internet-Draft MPLS MT October 2010
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 Multiple-TopologyID.
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 Multiple 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 April 21, 2011 [Page 3]
Internet-Draft MPLS MT October 2010
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 April 21, 2011 [Page 4]
Internet-Draft MPLS MT October 2010
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 April 21, 2011 [Page 5]
Internet-Draft MPLS MT October 2010
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 April 21, 2011 [Page 6]
Internet-Draft MPLS MT October 2010
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-
Topologyto 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.
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
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.
Li, et al. Expires April 21, 2011 [Page 7]
Internet-Draft MPLS MT October 2010
4. Requirements
4.1. 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.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.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,
unless there is a negotiation between the different service providers
to maintain the service level agreement for the MPLS-MT customer.
4.1.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.1.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
Li, et al. Expires April 21, 2011 [Page 8]
Internet-Draft MPLS MT October 2010
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.1.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.1.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
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.1.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.
Li, et al. Expires April 21, 2011 [Page 9]
Internet-Draft MPLS MT October 2010
4.1.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.1.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.1.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)
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.1.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.1.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
Li, et al. Expires April 21, 2011 [Page 10]
Internet-Draft MPLS MT October 2010
[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.1.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.1.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
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.
4.2. Provider requirements
This section describes operational requirements for a cost
-effective, profitable MPLS-MT service offering.
4.2.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
Li, et al. Expires April 21, 2011 [Page 11]
Internet-Draft MPLS MT October 2010
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.
4.2.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
systems. A MPLS-MT solution SHOULD support a large number of
customer interfaces on a single PE or CE with current Internet
protocols.
4.2.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.
4.2.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
Li, et al. Expires April 21, 2011 [Page 12]
Internet-Draft MPLS MT October 2010
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.
4.2.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.
4.2.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.
4.2.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.
4.2.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
Li, et al. Expires April 21, 2011 [Page 13]
Internet-Draft MPLS MT October 2010
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.
4.2.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.
4.3. Engineering requirements
These requirements are driven by implementation characteristics that
make service and provider requirements achievable.
4.3.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.
Li, et al. Expires April 21, 2011 [Page 14]
Internet-Draft MPLS MT October 2010
4.3.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.
4.3.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
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.
4.3.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.
Li, et al. Expires April 21, 2011 [Page 15]
Internet-Draft MPLS MT October 2010
4.3.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.
5. IANA Considerations
TBD
6. Acknowledgement
Thanks for the contributions from Quintin Zhao, Ravi Tori, Huaimo
Chen, Luyuang Fang, Chao Zhou.
7. References
7.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.
Li, et al. Expires April 21, 2011 [Page 16]
Internet-Draft MPLS MT October 2010
[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.
7.2. Informative References
Authors' Addresses
Lianyuan Li
China Mobile, Inc.
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: lilianyuan@chinamobile.com
Lu 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 75082
USA
Email: Ning.So@verizonbusiness.com
Li, et al. Expires April 21, 2011 [Page 17]
Internet-Draft MPLS MT October 2010
Amund Kvalbein
Resiliens Communication AS
Martin Linges v 17, Fornebu
Fornebu, Lysaker 1325
Norway
Email: Amundk@simula.com
Quintin Zhao
Huawei Technology
125 Nagog Park
Acton, MA 01919
US
Phone:
Email: qzhao@huawei.com
Huaimo Chen
Huawei Technology
125 Nagog Park
Acton, MA 01919
US
Phone:
Email: huaimochen@huawei.com
Ravi Tori
Juniper Networks
pratiravi@gmail.com
Li, et al. Expires April 21, 2011 [Page 18]