One document matched: draft-leymann-mpls-seamless-mpls-00.txt
Internet Engineering Task Force N. Leymann, Ed.
Internet-Draft Deutsche Telekom AG
Intended status: Informational October 20, 2009
Expires: April 23, 2010
Seamless MPLS Architecture
draft-leymann-mpls-seamless-mpls-00
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This documents describes an architecture which can be used to extend
MPLS networks to integrate access and aggregation networks into a
single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is
Leymann Expires April 23, 2010 [Page 1]
Internet-Draft Seamless MPLS October 2009
based on existing and well known protocols. It provides a highly
flexible and an scalable architecture and the possibility to
integrate 100.000 of nodes. The separation of the service and
transport plane is one of the key elements; Seamless MPLS provides
service independent transport and removes the necessarity for service
specific configurations in network elements. This draft describes
the deployment of standardized protocols and does not invent any new
protocols or defines extensions to existing protocols.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6
2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 9
2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 10
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 11
3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . . 13
4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . . 14
4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . . 14
4.6. Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 14
5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . . 14
5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2. General Network Topology . . . . . . . . . . . . . . . 15
5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 16
5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . . 16
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 16
Leymann Expires April 23, 2010 [Page 2]
Internet-Draft Seamless MPLS October 2009
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 16
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.5.1. LDP DoD . . . . . . . . . . . . . . . . . . . . . 17
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 18
5.1.7. Network Availability . . . . . . . . . . . . . . . . . 18
5.1.8. Multicast . . . . . . . . . . . . . . . . . . . . . . 18
5.1.9. Next-Hop Redundancy . . . . . . . . . . . . . . . . . 18
5.2. Deployment Scenario #2 . . . . . . . . . . . . . . . . . . 21
5.3. Scalability Analyses . . . . . . . . . . . . . . . . . . . 21
5.3.1. Control and Data Plane State for Deployment
Scenario #1 . . . . . . . . . . . . . . . . . . . . . 21
5.3.2. Control and Data Plane State for Deployment
Scenario #2 . . . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Leymann Expires April 23, 2010 [Page 3]
Internet-Draft Seamless MPLS October 2009
1. Introduction
MPLS as a mature and well known technology is widely deployed in
today's core and aggregation/metro area networks. Many metro area
networks are already based on MPLS delivering Ethernet services to
residential and business customers. Until now those deployments are
usually done in different domains; e.g. core and metro area networks
are handled as separate MPLS domains.
Seamless MPLS extents the core domain and integrates aggregation and
access domains into a single MPLS domain ("Seamless MPLS"). This
enables a very flexible deployment of an end to end service delivery.
In order to obtain a highly scalable architecture Seamless MPLS takes
into account that typical access devices (DSLAMs, MSAN) are lacking
some advanced MPLS features like BGP. Hence access devices are kept
as simple as possible.
Seamless MPLS is not a new protocol suite but describes an
architecture by deploying existing protocols like BGP, LDP and ISIS.
By being flexible on the choice of protocols (e,.g. for the
connection of access devices static routing or an arbitrary routing
protocol can be used) it is possible to apply Seamless MPLS to many
existing networks.
1.1. 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].
1.2. Terminology
This document uses the following terminology
o Access Node (AN): An access node is a node which processes
customers frames or packets at Layer 2 or above. This includes
but is not limited to DSLAMs or OLTs (in case of (G)PON
deployments). Access nodes have only limited MPLS functionalities
in order to reduce complexity in the access network.
o Aggregation Node (AGN): An aggregation node (AGN) is a node which
aggeegates several access nodes (ANs).
o Area Border Router (ABR): Router between aggregation and core
domain.
o Deployment Scenario:
Leymann Expires April 23, 2010 [Page 4]
Internet-Draft Seamless MPLS October 2009
o Transport Node (TN): Transport nodes are used to connect access
nodes to service nodes, and services nodes to services nodes.
Transsport nodes ideally have no customer or service state and
therefore decoupled from service creation.
o Seamless MPLS (S-MPLS): Used as a generic term to describe an
architecture which integrates access, aggreation and core network
in a single MPLS domain.
o Service Node (SN): A service node is used to create services for
customers and is connected to one or more transport nodes.
Typical examples include Broadband Network Gateways (BNGs), video
servers
o Transport Pseudo Wire (T-PW): A transport pseudowire provides an
service indepenent transport mechanisms based on a Pseudo-Wire
within the Seamless MPLS architecture.
o Use Case: Describes a typical network including service creation
points in order to describe the requirments, typical numbers etc.
which need to be taken into account when applying the Seamless
MPLS architecture.
2. Motivation
MPLS is deployed in core and aggregation network for several years
and provides a mature and stable basis for large networks. In
addition MPLS is already used in access networks, e.g. such as mobile
or DSL backhaul. Today MPLS as technology is being used on two
different layers:
o the Transport Layer and
o the Service Layer (e.g. for MPLS VPNs)
In both cases the protocols and the encapsulation are identical but
the use of MPLS is different especially concerning the signalling and
the control plane. On the service layer only service specific
information is exchanged; every service can potentially deploy it's
own architecture and individual protocols. The services are running
on top of the transport layer. Nevertheless those deployments are
usually isolated, focussed on a single use case and not integrated
into an end-to-end manner.
The motivation of Seamless MPLS is to provide an architecture which
supports a wide variety of different services on a single MPLS
platform fully integrating access, aggregation and core network. The
Leymann Expires April 23, 2010 [Page 5]
Internet-Draft Seamless MPLS October 2009
architecture can be used for residential services, mobile backhaul,
business services and supports fast reroute, redundancy and load
balancing. Seamless MPLS provides the deployment of service creation
points which can be virtually everywhere in the network. This
enables network and service providers with a flexible service and
service creation. Service creation can be done based on the existing
requirements without the needs for dedicated service creation areas
on fixed locations.
2.1. Why Seamless MPLS
Many aggregation networks are already deploying MPLS but are limited
to the use of MPLS per aggregation area. Those MPLS based
aggregation domains are connected to a core network running MPLS as
well. Nevertheless most of the services are not limited to an
aggregation domain but running between several aggregation domains
crossing the core network. In the past it was necessary to provide
connectivity between the different domains and the core on a per
service level and not based on MPLS (e.g. by deploying native IP-
Routing or Ethernet based technologies between aggregation and core).
In most cases service specific configurations on the border nodes
between core and aggregation were required. New services led to
additional configurations and changes in the provisioning tools (see
Figure 1).
With Seamless MPLS there are no technology boundaries. Network (or
region) boundaries are for scaling and manageability, and do not
affect packet forwarding, since the Transport Pseudowire that carries
packets from the AN to the SN doesn't care whether it takes two hops
or twenty, nor how many region boundaries it needs to cross. The
network architecture is about network scaling, network resilience and
network manageability; the service architecture is about optimal
delivery: service scaling, service resilience (via replicated SNs)
and service manageability. The two are decoupled: each can be
managed separately and changed independently.
+--------------+ +--------------+ +--------------+
| Aggregation | | Core | | Aggregation |
| Domain #1 +---------+ Domain +---------+ Domain #2 |
| MPLS | ^ | MPLS | ^ | MPLS |
+--------------+ | +--------------+ | +--------------+
| |
+------ service specific ------+
configuration
Figure 1: Service Specific Configurations
One of the main motivations of Seamless MPLS is to get rid of
Leymann Expires April 23, 2010 [Page 6]
Internet-Draft Seamless MPLS October 2009
services specific configurations between the different MPLS islands.
Seamless MPLS connects all MPLS domains on the MPLS transport layer
providing a single transport layer for all services - independent of
the service itself. The Seamless MPLS architecture therefore
decuples the service and transport layer and integrates access,
aggregation and core into a single platform. One of the big
advantages is that problems on the transport layer only need to be
solved once (and the solutions are available to all services). With
Seamless MPLS it is not necessary to use service specific
configurations on intermediate nodes; all services can be deployed in
an end to end manner.
2.2. Use Case #1
2.2.1. Description
In most cases at least residential and business services need to be
supported by a network. This section describes a Seamless MPLS use
case which supports such a scenario. The use case includes point to
point services for business customers as well as typical service
creation for residential customers.
+-------------+
| Service |
| Creation |
| Residential |
| Customers |
+------+------+
|
|
|
PW1 +-------+ +---+---+
######################### |
# +--+ AGN11 +---+ AGN21 + +------+
# / | | /| |\ | | +--------+
+--#-+/ +-------+\/ +-------+ \| | | remote |
| AN | /\ + CORE +---......--+ AN |
+--#-+\ +-------+ \+-------+ /| | ####### |
# \ | | | |/################### +--------+
# +--+ AGN12 +---+ AGN22 +##+------+ P2P Business Service
##############################
PW2 +-------+ +-------+
Figure 2: Use Case #1: Service Creation
Figure 2 shows the different service creation points and the
corresponding pseudowires between the access nodes and the service
creation points. The use case does not show all PWs (e.g. not the
Leymann Expires April 23, 2010 [Page 7]
Internet-Draft Seamless MPLS October 2009
PWs needed to support redundancy) in order to keep the figure simple.
Node and link failures are handled by rerouting the PWs (based on
standard mechanisms).
Residential Services: The service creation for all residential
customers connected to the Access Nodes in an aggregation domain
is located on an Service Node connected to the AGN2x. The PW
(PW1) originated at the AN and terminates at the AGN2. A second
PW is be deployed in the case where redundancy is needed on the AN
(the figure shows redundancy but this might not be the case for
all ANs in this Use Case). Additonal PWs can be deployed as well
in case more than a single service creation is needed for the
residential service (e.g. one service creation point for Internet
access and a second service creation point for IPTV services).
Business Sercvices: For business services the use cases shows point
to point connections between two access nodes. PW2 originiates at
the AN and terminates on the remote AN crossing two aggregation
areas and the core network. If the access node needs connections
to several remote ANs the corresponding number of PWs will
originated at the AN. Nevertheless taking the number of ports
available and the number of business customers on a typical access
node the number of PWs will be relatively small.
+-------+ +-------+ +------+ +------+
| | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
| | | | | | | |
+-------+ +-------+ +------+ +------+
static route ISIS L1 LDP ISIS L2 LDP
<-Access-><--Aggregation Domain--><---------Core--------->
Figure 3: Use Case #1: Redundancy
Figure 3 shows the redundancy at the access and aggregation network
deploying a two stage aggregation network (AGN1x/AGN2x).
Nevertheless redundancy is not a MUST in this use case. It is also
possible to use non redundant connection between the ANs and AGN1
stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is
used to aggregate traffic from several AGN1x pairs. In this use case
Leymann Expires April 23, 2010 [Page 8]
Internet-Draft Seamless MPLS October 2009
an aggregation domain is not limited to the use of a single pair of
AGN2x; the deployment of several AGN2 pairs within the domain is also
supported. As design goal for the scalability of the routing and
forwarding within the Seamless MPLS architecture the following
numbers are used:
o Number of Aggregation Domains: 100
o Number of Backbone Nodes: 1.000
o Number of Aggregation Nodes: 10.000
o Number of Access Nodes: 100.000
The access nodes (AN) are dual homed to two different aggregation
nodes (AGN11 and AGN12) using static routing entries on the AN. The
ANs are always source or sink nodes for MPLS traffic but not transit
nodes. This allows a light MPLS implementation in order to reduce
the complexity in the AN. The aggregation network consists of two
stages with redundant connections between the stages (AGN11 is
connected to AGS21 and AGS22 as well as AGS12 to AGS21 and AGS22).
The gateway between the aggregation and core network is realized
using the Area Border Routers (ABR). From the perspective of the
MPLS transport layer all systems are clearly identified using the
loopback address of the system. An ingress node must be able to
establish a service to an arbitrary egress system by using the
corresponding MPLS transport label
2.2.2. Typical Numbers
Table 1 shows typical numbers which are expected for Use Case #1
(access node).
+-------------------+---------------+
| Parameter | Typical Value |
+-------------------+---------------+
| IGP Control Plane | 2 |
| IP FIB | 2 |
| LDP Control Plane | 200 |
| LDP FIB | 200 |
| BGP Control Plane | 0 |
| BGP FIB | 0 |
+-------------------+---------------+
Table 1: Use Case #1: Typical Numbers for Access Node
Leymann Expires April 23, 2010 [Page 9]
Internet-Draft Seamless MPLS October 2009
2.3. Use Case #2
2.3.1. Description
2.3.2. Typical Numbers
3. Requirements
The following section describes the overall requirements which need
to be fulfilled by the Seamless MPLS architecture. Beside the
general requirements of the architecture itself there are also
certain requirements which are related to the different network
nodes.
o End to End Transport LSP: MPLS based services (pseudowire based,
L3-VPN or IP) SHALL be provided by the Seamless MPLS based
infrastructure.
o Scalability: The network SHALL be scalable to the minimum of
100.000 nodes.
o Fast convergence (sub second resilience) SHALL be supported. Fast
reroute (LFA) SHOULD be supported.
o Flexibility: The Seamless MPLS architecture SHALL be applied to a
wide variety of existing MPLS deployments. It SHALL use a
flexibly approach deploying building blocks with the possiblity to
use certain features only if those features are needed (e.g. dual
homing ANs or fast reroute mechanisms).
o Service independence: Service and transport layer SHALL be
decoupled. The architecture SHALL remove the need for service
specific configurations on intermediate nodes.
o Native Multicast support: P2MP mechanisms SHOULD be supported by
the Seamless MPLS architecture.
o Interoperable OAM mechanisms SHALL be implemented
3.1. Overall
3.1.1. Access
The access network should be kept as simple as possible. Compared to
the aggregation and/or core network within Seamless MPLS a typical
access node is less powerful. The control plane and the forwarding
should be as simple as possible. To reduce the complexity and the
Leymann Expires April 23, 2010 [Page 10]
Internet-Draft Seamless MPLS October 2009
costs of an access node not the full MPLS functionality need to be
supported (control and data plane). The use of an IGP should be
avoided. Static routing should be sufficient. Required
functionality to reach the required scalability should be moved out
of the access node. The number of access nodes can be very high.
The support of load balancing for layer 2 services should be
implemented.
3.1.2. Aggregation
The aggregation network aggregates traffic from access nodes. The
aggregation Node must have functionalities that enlarge the
scalability of the simple access nodes that are connected. The IGP
must be link state based. Each aggregation area must be a separated
area. All routes that are interarea should use an EGP to keep the
IGP small. The aggregation node must have the full scalability
concerning control plane and forwarding. The support of load
balancing for layer 2 services must be implemented.
3.1.3. Core
The core connects the aggregation areas. The core network elements
must have the full scalability concerning control plane and
forwarding. The IGP must be link state based. The core area must
not include routes from aggregation areas. All routes that are
interarea should use an EGP to keep the IGP small. Each area of the
link state based IGP should have less than 2000 routes. The support
of load balancing for layer 2 services must be implemented.
3.2. Multicast
Compared with unicast connectivity Multicast is more dynamic. User
generated messages - like joining or leaving multicast groups - are
interacting directly with network components in the access and
aggregation network (in order to build the corresponding forwarding
states). This leads to to the need for a highly dynamic handling of
messages on access and aggregation nodes. Nevertheless the core
network SHOULD be stable and state changes triggered by user
generated messages SHOULD be minimized. This rises the need for an
hierarchy for the P2MP support in Seamless MPLS hiding the dynamic
behaviour of the access and aggregation nodes
o mLDP
o P2MP RSVP-TE
Leymann Expires April 23, 2010 [Page 11]
Internet-Draft Seamless MPLS October 2009
3.3. Availability
All network elements should be high available (99.999% availability).
Outage times should be as low as possible. A repair time of 50
milliseconds or less should be guarantied at all nodes and lines in
the network that are redundant. Fast convergence features SHOULD be
used in all control plane protocols. Local Repair functions SHOULD
be used wherever possible. Full redundancy is required at all
equipment that is shared in a network element.
o Power Supply
o Switch Fabric
o Routing Processor
A change from an active component to a standby component SHOULD
happen without effecting customers traffic. The Influence of
customer traffic MUST be as low as possible.
3.4. Scalability
The network must be highly scalable. As a minimum requirement the
following scalability figures should be met:
o Number of aggregation domains: 100
o Number of backbone nodes: 1.000
o Number of aggregation nodes: 10.000
o Number of access nodes: 100.000
3.5. Stability
o The platform should be stable under certain circumstances (e.g.
missconfiguration within one area should not cause instability in
other areas).
o Differentiate between "All Loopbacks and Link addresses should be
ping able from every where." Vs. "Link addresses are not
necessary ping able from everywhere".
Leymann Expires April 23, 2010 [Page 12]
Internet-Draft Seamless MPLS October 2009
4. Architecture
4.1. Overall
One of the key questions that emerge when designing an architecture
for a seamless MPLS network is how to handle the sheer size of the
necessary routing and MPLS label information control plane and
forwarding plane state resulting from the stated scalability goals
especially with respect to the total number of access nodes. This
needs to be done without overwhelming the technical scaling limits of
any of the involved nodes in the network (access, aggregation and
core) while at the same time still maintaining good convergence
properties to allow for quick MPLS transport and service restoration
in case of network failures.
4.2. Multi-Domain MPLS networks
The key design paradigm that leads to a sound and scalable solution
is the divide and conquer approach, whereby the large problem is
decomposed into many smaller problems for which the solution can be
found using well-known standard architectures.
In the specific case of seamless MPLS the overall MPLS network SHOULD
be decomposed into multiple MPLS domains, each well within the
scaling limits of well-known architectures and network node
implementations. From an organizational and operational point of
view it MAY make sense to define the boundaries of such domains along
the pre-existing boundaries of aggregation networks and the core
network.
Examples of how networks can be decomposed include using IGP areas as
well as using multiple BGP autonomous systems.
4.3. Hierarchy
These MPLS domains SHOULD then be then be connected into an MPLS
multi-domain network in a hierarchical fashion that enables the
seamless exchange of loopback adresses and MPLS label bindings for
transport LSPs across the entire MPLS internetwork while at the same
time preventing the flooding of unnecessary routing and label binding
information into domains or parts of the network that do not need
them. Such a hierarchical routing and forwarding concept allows a
scalability in different dimensions and allows to hide the complexity
and size of the aggregation and access networks.
Leymann Expires April 23, 2010 [Page 13]
Internet-Draft Seamless MPLS October 2009
4.4. Intra-Domain Routing
The intra-domain routing within each of the MPLS domains (i.e.
aggregation domains and core) SHOULD utilize standard IGP protocols
like OSPF or ISIS. By definition, each of these domains is small
enough so that there are no relevant scaling limits within each IGP
domain, given well-known state-of-the-art IGP design principles and
recent router technology.
The intra-domain MPLS LSP setup and label distribution SHOULD utilize
standard protocols like LDP or RSVP.
4.5. Inter-Domain Routing
The inter-domain routing is responsible for establishing connectivity
between and across all MPLS domains. The inter-domain routing SHOULD
establish a routing and forwarding hierarchy in order to achieve the
scaling goals of seamless MPLS. Note that the inter-area routing of
IGP protocols like OSPF and ISIS do not achive this goal in an MPLS
context, where FECs for loopback addresses cannot be aggregated.
Therefore it is RECOMMENDED to utilize protocols that support
indirect next-hops (like BGP with MPLS labels "labled BGP/SAFI4"
[RFC3107]).
4.6. Core
4.7. Aggregation
4.8. Access
5. Deployment Scenarios
This section describes the deployment scenarios based on the use
cases and the gerenic architecture above.
5.1. Deployment Scenario #1
Section describing the Seamless MPLS implementation of a large
european ISP.
5.1.1. Overview
This deployment scenario describes one way to implement a seamless
MPLS architecture. Specific to this implementation is the choice of
intra- and inter-domain routing and label distribution protocols, as
well as the details of the interworking of these protocols to achieve
Leymann Expires April 23, 2010 [Page 14]
Internet-Draft Seamless MPLS October 2009
the overall scalable hierarchical architecture.
5.1.2. General Network Topology
There are multiple aggregation domains (in the order of up to 100)
connected to the core in a star topology, i.e. aggregation domains
are never connected among themselves, but only to the core. The core
has its own domain.
+-------+ +-------+ +------+ +------+
| | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/ |
+----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
| | | | | | | |
+-------+ +-------+ +------+ +------+
static route ISIS L1 LDP ISIS L2 LDP
<-Access-><--Aggregation Domain--><---------Core--------->
Figure 4: Deployment Scenario #1
As shown in Figure 4, the DSLAMs, or access nodes (AN) are connected
to the aggregation network via aggregation nodes called AGS1, either
to a single AGS1 or redundantly to two AGS1. Each AGS1 has redundant
uplinks to a pair of second-level aggregation nodes called AGS2.
Each aggregation domain is connected to the core via exactly 2 border
routers (ABR) on the core side. There can be multiple AGS2 pairs per
aggregation domain, but only one ABR pair for each aggregation
domain. Each of the AGS2 in an AGS2 pair connects to one of the ABRs
in the ABR pair responsible for that aggregation domain.
The ABRs on the core side have redundant connections to a pair of LSR
routers.
The LSR pair is also connected via a direct link.
The core LSR are connected to other core LSR in a partly meshed
topology so that there are disjunct, redundant paths from each LSR to
each other LSR.
Leymann Expires April 23, 2010 [Page 15]
Internet-Draft Seamless MPLS October 2009
5.1.3. Hierarchy
As explained before, hierarchy is the key to a scalable seamless MPLS
architecture. The hierarchy in this implementation is achieved by
forming different MPLS domains for aggregation domains and core,
where within each of these domains a faily common MPLS deployment
using ISIS as intradomain link-state routing protocol and using LDP
for MPLS label distribution is used.
These MPLS domains are mapped to ISIS areas as follows: Aggregation
domains are mapped to ISIS L1 areas. The core is configured as ISIS
L2. The border routers connecting aggregation and core are ISIS L1L2
and are referred to as ABRs. From a technical and operational point
of view these ABRs are part of the core, althought they also belong
to the respective aggregation domain purely from a routing protocol
point of view.
For the interdomain-routing BGP with MPLS labels is deployed ("labled
BGP/SAFI4" [RFC3107]).
5.1.4. Intra-Area Routing
5.1.4.1. Core
The core uses ISIS L2 to distribute routing information for the
loopback addresses of all core nodes. The border routers (ABR) that
connect to the aggregation domains are also part of the respective
aggregation ISIS L1 area and hence ISIS L1L2.
LDP is used to distribute MPLS label binding information for the
loopback addresses of all core nodes.
5.1.4.2. Aggregation
The aggregation domains uses ISIS L1 as intra-domain routing
protocol. All AGS loopback addresses are carried in ISIS.
As in the core, the aggregation also uses LDP to distribute MPLS
label bindings for the loopback addresses.
5.1.5. Access
Access nodes do not have their own domain or IGP area. Instead, they
directly connect to the AGS1 nodes in the aggregation domain. To
keep access devices as simple as possible, ANs do not participate in
ISIS.
Instead, each AN has two static default routes pointing to each of
Leymann Expires April 23, 2010 [Page 16]
Internet-Draft Seamless MPLS October 2009
the AGS1 it is connected to. Appropriate techniques have to be
deployed to make sure that a given default route is invalidated when
the link to an AGS1 or that node itself fails. Examples of such
techniques include monitoring the pysical link state for loss of
light/loss of frame, or using Ethernet link OAM or BFD
[I-D.ietf-bfd-v4v6-1hop].
The AGS1 MUST have a configured static route to the loopback address
of each of the ANs it is connected to, because it cannot learn the AN
loopback address in any other way. These static routes have to be
monitored and invalidated if necessary using the same techniques as
described above of the static default routes on the AN.
The AGS1 redistributes these routes into ISIS for intra-domain
reachability of all AN loopback addresses.
LDP is used for MPLS label distribution between AGS1 and AN. In
order to keep the AN control plane as lightweight as possible, and to
avoid the necessity for the AN to store 100.000 MPLS label bindings
for each upstream AGS1 peer, LDP is deployed in downstream-on-demand
(DoD) mode, described below.
To allow the label bindings received via LDP DoD to be installed into
the LFIB on the AN without having the specific host route to the
destination loopback address, but only a default route, we make use
of the LDP Extension for Inter-Area Label Switched Paths [RFC5283].
5.1.5.1. LDP DoD
LDP downstream-on-demand mode is specified in [RFC5036]. Although is
was originally intended to be used with ATM switch hardware, there is
nothing from a protocol perspective preventing the use in a regular
MPLS frame-based environment. In this mode the upstream LSR will
explicitly ask the downstream LSR for a label binding for a
particular FEC when needed.
The assumption is that a given AN will only have a limited number of
services configured to an even more limited number of destinations,
or egress PE. Instead of learning and storing all label bindings for
all possible loopback addresses within the entire seamless MPLS
network, the AN will use LDP DoD to only request the label bindings
for the FECs corresponding to the loopback addresses of those egress
nodes to which it has services configured.
For LDP DoD the router/AGS must ask the DSLAM/MSAN for FECs. FECs
are necessary for all pseudowire destinations at the MSAN. Most
preferable this pseudowire destination is the LSR-ID of the MSAN.
Depending on the MSAN implementation and architecture multiple
Leymann Expires April 23, 2010 [Page 17]
Internet-Draft Seamless MPLS October 2009
pseudowire destination addresses and associated FECs could be needed.
The conclusion of this results to the following requirement:
o The router/AGS must ask the MSAN for FECs for all potential
pseudowire destinations. This potential pseudowire destinations
must be configured at the router/AGS. The MSAN knows to which
destination a pseudowire is setup. The MSAN is always the
endpoint of the pseudowire. Before signalling a pseudowire the
MSAN must ask (via DoD) the AGS for a FEC. Because of this a
independent preconfiguration is not necessary (at MSAN). Because
the AGS (at least in many cases) does not take part at the
pseudowire signaling an independent way of receiving the MSAN FEC
is necessary at the AGS.
o Optionally an automatism that asks for a FEC for the LSR-ID could
be implemented. A switch that disables this option must be
implemented. The label is necessary. The way of initiating the
DoD-signaling of the label could be done with both methods
(configuration/automatism).
o The following are the triggers for MSANs to request a label
o
* When a control session (targeted LDP) to a target has to be
established
* When a service label has been received by a control session
(e.g. pseudo wire lable
5.1.6. Inter-Area Routing
For the interdomain-routing BGP with MPLS labels is deployed ("labled
BGP/SAFI4" [RFC3107]). [RFC4364]
5.1.7. Network Availability
5.1.8. Multicast
5.1.9. Next-Hop Redundancy
An aggregation domain is connected to the core network using two
redundant area boarder routers. If one of the systems fails
rerouting can be performed using the standard BGP mechanisms.
Unfortunately this will take longer than the required 50ms.
Nevertheless the goal is to support IP/LDP fast reroute for fast
convergence in the backbone and the core parts of the network. To be
fast failures should be tackled by using a local repair; the failure
Leymann Expires April 23, 2010 [Page 18]
Internet-Draft Seamless MPLS October 2009
will be corrected by an system next to it's occurrence.
+-------+
| |
vl0+ ABR 1 |
/| |
+----------+ +-------+ / +-------+
| | | |/
| PE / LER +----+ PLR |
| | | |\
+----------+ +-------+ \ +-------+
\| |
vl0+ ABR 2 |
| |
+-------+
+-------+ +-------+ +-------+
| LDP-L +-----+ LDP-L +-----+ LDP-L |
+-------+ +-------+ +-------+
| BGP-L +-------------------+ BGP-L |
+-------+ +-------+
--------------- traffic ---------------->
<----- routing + label distribution -----
Figure 5: Routing and Traffic Flow
In order to deploy local repair also when an area border router fails
an additional mechanism is used (see Figure 5) with the PLR being the
point of local repair. ABR1 advertises in addition to it's loopback
address in ISIS and LDP a virtual loopback address (vl0). ABR2 is
backup router and advertises the same address as well with a worse
metric. If ABR1 fails the PLR can immediately locally switch to the
alternative path towards ABR2 (anycast behaviour). If this anycast
address is used as next hop within the labled BGP a local repair for
the MPLS transport layer can be performed.
Leymann Expires April 23, 2010 [Page 19]
Internet-Draft Seamless MPLS October 2009
+-----------------+-----------+-----------+
| FEC 10.0.1.1/32 | Label 200 | NH AGS2-1 |
+-----------------+-----------+-----------+
| FEC 10.0.1.2/32 | Label 233 | NH AGS2-1 | ABR1
+-----------------+-----------+-----------+
| FEC 10.0.1.3/32 | Label 313 | NH AGS2-1 |
+-----------------+-----------+-----------+
+------+ +-------+
| | | | +------------------+
vl0+ ABR1 +----+ AGS21 +----+ AGN11:10.0.1.1/32|
/| | | |\ /+------------------+
/ +------+\ /+-------+ \/
+----+ +-----+/ \/ \ /\ +------------------+
| PE +---+ PLR | /\ X X+ AGN12:10.0.1.2/32|
+----+ +-----+\ / \ / \/ +------------------+
\ +------+ +-------+ /\
\| | | |/ \+------------------+
vl0+ ABR2 +----+ AGS22 +----+ AGN13:10.0.1.3/32|
| | | | +------------------+
+------+ +-------+
+----------------------------------------+
| native forwarding context |
+-----------------+-----------+----------+
| FEC 10.0.1.1/32 | Label 100 | NH AGS21 |
+-----------------+-----------+----------+
| FEC 10.0.1.2/32 | Label 107 | NH AGS21 | ABR2
+-----------------+-----------+----------+
| FEC 10.0.1.3/32 | Label 152 | NH AGS21 |
+-----------------+-----------+----------+
| | |
V V V
+----------------------------------------+
| backup forwarding context |
+-----------------+-----------+----------+
| FEC 10.0.1.1/32 | Label 200 | NH AGS21 |
+-----------------+-----------+----------+
| FEC 10.0.1.2/32 | Label 233 | NH AGS21 | ABR2
+-----------------+-----------+----------+
| FEC 10.0.1.3/32 | Label 313 | NH AGS21 |
+-----------------+-----------+----------+
(ABR2 acting as backup for ABR1)
Figure 6: ABR Failure Scenario
Figure 6 shows the behaviour in case of an ABR failure. ABR2 creates
Leymann Expires April 23, 2010 [Page 20]
Internet-Draft Seamless MPLS October 2009
a backup forwarding context for labled BGP routes which are routed
via ABR1. This local backup forwarding context is not part of the
global lable table. ABR2 advertises over LDP as anycast next-hop not
implicit null but an explicit label which points internally to the
backup context. ABR2 learns via BGP the labels used by ABR1 for the
connected aggregation domain(s). In addition ABR2 carries also label
forwarding states for the corresponding FECs. By combining those two
informations the backup forwarding context is filled with valid label
forwarding entries. MPLS frames carrying the correct label for the
forwarding by ABR1 as second entry in the label stack are also
correctly forwarded by ABR2 using this information.
5.2. Deployment Scenario #2
5.3. Scalability Analyses
5.3.1. Control and Data Plane State for Deployment Scenario #1
5.3.2. Control and Data Plane State for Deployment Scenario #2
6. Acknowledgements
Many people contributed to this document. The authors wish to thank
- in alphabetical order:
o Wim Henderickx (Alcatel)
o Clarence Filsfils (Cisco Networks),
o Thomas Beckhaus, Wilfried Maas, Dirk Steinberg, Roger Wenner
(Deutsche Telekom),
o Kireeti Kompella (Juniper Networks),
7. IANA Considerations
This memo includes no request to IANA.
All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
for a guide). If the draft does not require IANA to do anything, the
section contains an explicit statement that this is the case (as
above). If there are no requirements for IANA, the section will be
removed during conversion into an RFC by the RFC Editor.
Leymann Expires April 23, 2010 [Page 21]
Internet-Draft Seamless MPLS October 2009
8. Security Considerations
In a typical MPLS deployment the use of MPLS is limited to relatively
small network consisting of core and edge nodes. Those nodes are
under full control of the services provider and placed at locations
where only authorized personal has access (this also includes
physical access to the nodes). With the extensions of MPLS towards
access and aggregation nodes not all nodes will be "locked away" in
secure locations. Small access nodes like DSLAMs will be located in
street cabinets, potentially offering access to the "interested
researcher". Nevertheless the unauthorized access to such in device
SHOULD NOT impose any security risks to the MPLS infrastructure
itself. Seamless MPLS must be stable regarding attacks against
access and aggregation nodes running MPLS.
Levels of Security: tbd.
Access Network: tbd.
Aggregation Network: tbd.
Core Network: tbd.
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-bfd-v4v6-1hop]
Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-10 (work in progress),
October 2009.
[I-D.kothari-henderickx-l2vpn-vpls-multihoming]
Kothari, B., Kompella, K., Henderickx, W., and F. Balus,
"BGP based Multi-homing in Virtual Private LAN Service",
draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work
in progress), July 2009.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
Leymann Expires April 23, 2010 [Page 22]
Internet-Draft Seamless MPLS October 2009
progress), March 2008.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[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.
[RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul,
F., and F. Ansari, "Overview of IP Multicast in a Multi-
Protocol Label Switching (MPLS) Environment", RFC 3353,
August 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008.
Leymann Expires April 23, 2010 [Page 23]
Internet-Draft Seamless MPLS October 2009
Author's Address
Nicolai Leymann (editor)
Deutsche Telekom AG
Winterfeldtstrasse 21
Berlin 10781
DE
Phone: +49 30 8353-92761
Email: n.leymann@telekom.de
Leymann Expires April 23, 2010 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-23 00:55:06 |