Internet DRAFT - draft-gibson-mpls-srcroute
draft-gibson-mpls-srcroute
CCAMP M. Gibson
Internet Draft Nortel Networks
Document: draft-gibson-mpls-srcroute-00.txt February 2001
Category: Informational
Achieving Assured Service Levels through Source Routed MPLS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [STANDARD].
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.
Abstract
This memo sets out an MPLS-based solution to the IP service delivery
problems as set out in RFC 2990. The solution is based on source
routing of IP flows using MPLS label stacks.
The solution elements are introduced sequentially and a usage
scenario is mapped out that aligns with the work in the ISSLL working
group.
Conventions used in this document
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 [KEY-WORDS].
Gibson Informational - August 2001 1
draft-gibson-mpls-srcroute-00.txt Feb 2001
Table of Contents
Abstract.......................................................1
Conventions used in this document..............................1
1.0 Introduction...............................................3
1.1 Background to Solution....................................3
1.2 Scope of the Solution.....................................4
2.0 Key Network Components.....................................4
2.1 Flow Aggregation Schemes...................................5
2.2 Network Configuration and Control..........................5
2.2.1 Core Configuration.......................................7
2.2.2 Core Management..........................................7
2.2.3 Cross-connecting LSPs....................................8
2.2.4 Alternate XC label distribution mechanisms...............9
2.2.5 Source Routing..........................................10
2.2.6.1 Scalability...........................................11
2.2.6.2 Alternative Source Route discovery mechanisms.........11
2.3 Admission Control.........................................12
2.4 Route Selection...........................................13
2.4.1 Destination Service Notification Techniques.............14
2.5 Application of VPN techniques.............................15
2.6 Inter-operator requirements...............................16
2.7 Protection Strategies.....................................16
2.7.1 Protection across an AS.................................16
2.7.2 Protection of sessions..................................17
2.8 Applicability to RSVP aggregation.........................17
3.0 Future work...............................................18
4.0 Intellectual Property Considerations......................18
5.0 Security Considerations...................................18
6.0 References................................................18
7.0 Acknowledgments...........................................21
8.0 Author's Addresses........................................21
Appendix A....................................................22
Full Copyright Statement......................................24
Gibson Informational August 2001 2
draft-gibson-mpls-srcroute-00.txt Feb 2001
1.0 Introduction
RFC 2990 [RFC 2990] entitled "Next Steps for the IP QoS Architecture"
highlights the outstanding architectural issues relating to the wide-
scale deployment and use of QoS mechanisms within IP networks.
This memo proposes some of the key elements of an architectural
solution to solve the identified issues. It is based on a source
routing paradigm that builds upon key elements and protocols
contained within MPLS, Intserv, Diffserv and VPNs. Minor extensions
to the main protocols in these areas necessary to implement this
solution are outlined.
The reason for pursuing source routing is that if the service
availability of each network element in a route can be known at
source, then packets can be routed across a network with absolute
service guarantees.
By maintaining a number of independent source routes, it is possible
to achieve the traffic engineering and load balancing vital to QoS
routing. It is therefore possible to remove the need for crankback
during path computation, while achieving the same functionality.
Finally source routing retains the network intelligence at the edge
of the network and therefore sits comfortably with current Internet
technologies.
1.1 Background to Solution
RFC 2990 defines the key objectives an IP QoS architecture as:
o To control the network service response such that the response
to a specific service element is consistent and predictable.
o To control the network service response such that a service
element is provided with a level of response equal to or above a
guaranteed minimum.
o To allow a service element to establish in advance the service
response that can or will be obtained from the network.
o To control the contention for network resources such that a
service element is provided with a superior level of network
resource.
o To control the contention for network resources such that a
service element does not obtain unfair allocation of resources
(to some definition of 'fairness')
o To allow for efficient total utilisation of network resources
while servicing a spectrum of directed network service outcomes.
Gibson Informational August 2001 3
draft-gibson-mpls-srcroute-00.txt Feb 2001
It concludes that to meet these, in their current form neither the
solutions proposed in the IntServ or DiffServ working groups provide
a full solution. It is suggested that some middle ground solution,
borrowing from the best practices of both solutions would provide an
optimum solution.
This memo also takes this view, and offers a network outline building
upon the mechanisms of both solutions and scoping possible
enhancements to their operation. Consideration is made of suitable
core aggregation techniques that permit service level guarantees to
be honoured. The proposal includes methods of determining the most
favourable aggregate flow paths across a network core onto which a
flow might be mapped. This uses core network state feedback and
several methods by which this might be achieved are outlined.
The target services for the proposed solution can be referred to as
those that generate Real Time over IP (RToIP) flows. It is
anticipated that all such services will generate some form of
signaling (and negotiation) prior to the transmission of their first
packet.
1.2 Scope of the Solution
The scope of this solution is to recommend the protocols that could
be used to construct a network that meets the requirements specified
above. Where appropriate, useful extensions to these protocols are
specified. Included in this approach is a view on how these
extensions would be integrated with RSVP.
Out of scope of this memo are examples of specific application level
stimulus protocols for RToIP flows and the means by which the
establishment of the parameters and endpoints of such flows are
negotiated (e.g. SIP). Also, there will be no detailed consideration
of how QoS requirements in the collector LAN networks at the edge of
the core network will be provided.
2.0 Key Network Components
This sections aims to set out both the key functional components for
a network that supports the requirements set out in [RFC 2990], and a
set of candidates that fulfil the functionality.
The basic premise for the overall network topology is that the core
will consist of a number of Autonomous Systems (AS) across which
RToIP flows will be routed. Each AS will operate some form of logical
mesh of connectivity, in that all exit points of the AS are reachable
from any entry point.
Users will gain access to this network via an Edge Router (ER) that
sits at a logical edge of an AS. These users will typically be part
Gibson Informational August 2001 4
draft-gibson-mpls-srcroute-00.txt Feb 2001
of a LAN, or other such collector network. It will be assumed that
users will signal their service level requirements using RSVP. This
signalling will be used by the network to determine a suitable path
across the network that can support the Service level requirements of
the flow (without impacting the service experienced by existing
flows).
No RSVP Path state will be stored in the core network. The core
network will consist entirely of aggregate flows.
2.1 Flow Aggregation Schemes
Two flow aggregation schemes offer themselves as candidates for the
network core. The most obvious of these of DiffServ, which relies on
edge based admission control to a set of forwarding behaviours across
a network. This is a relatively simple solution but it is limited in
that it is only possible to manage the total network resource of a
service class, rather than on a per-destination basis.
Recent work has enhanced this basic operation using a combined
DiffServ and MPLS approach described in [DIFF_MPLS] that permits the
assignment of a forwarding behaviour to an LSP. By further extending
this to encompass explicit routing of LSPs across a network and
adopting the use of L-LSPs, the resource on a network can be
partitioned and allocated to each aggregate flow. By then performing
Policy-based admission control to each LSP, the service requirements
for an RToIP flow can effectively be met.
However, as most RToIP flows are described by bandwidth constraints,
if explicitly routed LSPs are to be used it would possibly be more
straightforward to use the bandwidth definition mechanisms that
already exist for ER-LSPs in their negotiation protocols RSVP-TE and
CR-LDP. This makes the monitoring of available resource on these LSPs
more straightforward.
This memo will therefore adopt the use of CR-LDP or RSVP-TE to
establish known bandwidth ER-LSPs, noting that explicitly routed L-
LSPs could also provide a workable solution.
2.2 Network Configuration and Control
For large national and international networks it is assumed that
typical RToIP flows will have to traverse two or more Autonomous
Systems. Furthermore it is assumed that each AS will be configured
with a full mesh of MPLS LSPs. These LSPs provide connectivity
between the edge points of the network. The case of ASs that are too
large to such that this full mesh assumption is invalidated is for
further study.
Gibson Informational August 2001 5
draft-gibson-mpls-srcroute-00.txt Feb 2001
The LSPs on each AS are provisioned by an off-line Policy Management
function (see later section for details). The Policy Manager is
responsible for configuring the connections across an AS. This
function therefore maintains a topological picture of the connections
on the AS. In addition to defining the service connectivity across
the AS, the Policy Manager is also responsible for defining the MPLS
recovery strategy to be used. This also forms a part of the delivered
service level by providing a prescribed level of service continuity.
In order to control the allocation of network resource, admission
control is enforced at the edge of each AS. Each ER is administered
by a controller termed an MPLS Bandwidth Broker (MBB). An MBB may
control more than one ER, though a single ER will only be controlled
by a single MBB.
The interconnection of these control elements can be seen in Figure
1.
Figure 1. Architectural components of RToIP solution
+-------+ +-------+
|Policy | |Policy |
"|Manager|" "|Manager|"
" +-------+ " " +-------+ "
" " " "
" " " "
+---+ +---+ +---+ "+---+
|MBB| |MBB| |MBB| |MBB|
+---+ -------- +---+ +---+ -------- +---+
: // \\ : : // \\ :
: // \\ : : // \\ :
: / \ : : / \ :
: | | : : | | :
+--+ +--+ +--+ +--+
|ER| AS |ER****ER| AS |ER|
+--+ +--+ +--+ +--+
| | | |
\ / \ /
\\ // \\ //
\\ // \\ //
-------- --------
Gibson Informational August 2001 6
draft-gibson-mpls-srcroute-00.txt Feb 2001
2.2.1 Core Configuration
Each AS in the core network is configured with a logical mesh of LSPs
with a defined service level between known ERs. This provides each ER
with a route, defined by a single LSP, to each other ER on the AS.
Routing decisions are therefore simplified to choosing the correct
LSP for the destination IP address of the RToIP flow.
To support multiple services with diverse characteristics, the mesh
may be extended to have a number of logically parallel LSPs between
a set of edge points, each configured to handle certain service
types.
2.2.2 Core Management
The configuration of the network is controlled by the Policy Managers
shown in figure 1. These are responsible for the service level
specific policy that is used to define connections across each AS.
This policy information can be described using the MPLS Policy
information model defined in [chadha].
The Policy information might also contain the SLAs of the users who
access the network. Knowledge of this information will help the
Policy Manager decide how to configure the network initially. By
creating dynamic SLAs that can be added as required and whose
requirements might change over time, it is also possible to add
dynamic reconfiguration of the network into the suite of network
services.
The Policy information at the Policy manager is converted into
provisioning information at the MBB. The MBB then uses this to
provision each of its ERs with the necessary connections across the
AS to support the services offered. The MBB therefore has a complete
knowledge of the reachable nodes (i.e. other ERs) from an ER it
controls, the label(s) that identify each of these connections and
the service levels supported by each connection.
The MBB can use either SNMP/SNMPCONF with suitable MPLS-TE MIBs [LSR-
MIB, LDP-MIB, TE-MIB] or COPS-MPLS [COPS-MPLS] with a suitably
developed PIB for this function.
In some scenarios this may offer a sufficient level of management.
Each MBB can set the forwarding rules for each type of RToIP flow at
the edge of an AS. When a packet arrives at the end of its previous
LSP, its IP header is processed and a suitable next-hop LSP is
determined. This fails to address the issue caused by inconsistent
SLA mapping of the packet onto a forwarding LSP.
The issue of establishing the service level across the boundaries of
a ASs is therefore considered in the following sections.
Gibson Informational August 2001 7
draft-gibson-mpls-srcroute-00.txt Feb 2001
2.2.3 Cross-connecting LSPs
The Multiprotocol Label Switching Architecture specification [RFC
3031] introduces BGP-4 as a method of piggy-backing label information
between edge routers. This label distribution technique originated in
work that used BGP as a VPN label distribution mechanism [RFC 2547],
however the methodology is documented separately as a standalone
technology [BGP-MPLS].
BGP-MPLS provides two key features that can be used in the
implementation of guaranteed service networks that span Autonomous
Systems.
o Labels distributed in a BGP Update message may be used to
indicate that a certain destination (defined in the Network
Layer Reachability Information (NLRI) field) is reachable via
the router identified in the Next Hop field of the Update
message.
o A BGP speaker may maintain (and advertise to its peers) more
than one route to a given destination, as long as each such
route has its own label(s).
Consider the network configuration shown in Figure 2. The routers L
and M on Autonomous System AS1 are BGP peers with routers J and K on
Autonomous Systems AS2. Both J and K advertise themselves as
providing connectivity to D. In AS1, L advertises itself as the Next
Hop to D on AS 2 and associates this route with label La. Lilkewise M
advertises a route to D on ASS2 and associates a different label, Lb,
with this route. At router O, there therefore exists two possible
routes to D via two next hops, either of which it may choose.
AS1 and As2 are thus configured with a full mesh of LSPs between edge
routers. The label that identifies the LSP from O to L is Ll and the
corresponding label to reach M is Lm. The label stack used at O to
identify the route to D would consist of the top label used to reach
the chosen next hop router and the bottom label used to reach D e.g.
Lm/Lb or Ll/La.
Gibson Informational August 2001 8
draft-gibson-mpls-srcroute-00.txt Feb 2001
Figure 2 Cross connection of LSPs using BGP labels
-------- | --------
// \\ | // \\
/ \+---+ |+---+/ \
/ AS1 <- | L |-+| J | AS2 \
| La +---+ |+---+ |
+---+ | | | +---+
| O | | | | | D |
+---+ Lb +---+ +---+ +---+
\ <- | M |-+| K | /
\ /+---+ |+---+\ /
\\ // | \\ //
-------- | --------
+-> |
|
common subnet
The labels La and Lb identify the next-hop LSP on AS2 that should be
used to reach D. In this way, these labels are identifying a cross-
connection between the incoming LSP and the egress LSP on AS2. To
distinguish these cross-connecting labels from those associated with
LSPs they will be referred to as XC-labels in the remainder of this
memo.
This XC label concept has powerful connotations. For example, when
managing the flow of traffic in the network, it is desirable to be
able to modify the traffic load on certain network links by re-
routing it across other, perhaps more lightly loaded links. This is
easily achieved through the use of the XC-label by changing its
forwarding mapping. The modification of this mapping could be
achieved through any of the MPLS provisioning techniques listed in
Section 2.2.2 and could be instigated by an MBB.
This ability to redirect traffic away from or around network hot-
spots is a key component when delivering a high performance network
for IP services.
2.2.4 Alternate XC label distribution mechanisms
An alternative to the use of BGP-MPLS distributed labels to enable
the XC function described above is through the use of tunnel-in-
tunnel LSP creation. In this method, a new LSP is created that has a
pre-configured mesh LSP as its route. This has causes the creation of
a new label at the ingress interface of the target ER that is sent
back to the originating ER. This label can then be configured at the
Gibson Informational August 2001 9
draft-gibson-mpls-srcroute-00.txt Feb 2001
target LER as an index into the label table and be made to point at
the correct next hop LSP.
This method would require the relaxation of the MPLS peering
relationship to allow its proper operation. A single LSR-LSR peer
pair create the label, however this label would require distribution
to all other ERs that want to access the XC. This functionality could
be achieved through the Policy layer as a means of distributing this
label. The MPLS MIBs, for example, already supports the pushing of a
label at its mplsXCEntry (specifically the
mplsXCLabelStackIndex)[LSR-MIB].
A suitable inter-MBB protocol could be used for this process. As a
part of the provisioning process, LSP labels are learned at the
management layer. These can then be disseminated at this higher layer
to those other management layer functions that need to know them. In
many ways this is a better solution than the relaxed peering approach
as it is the management layer that will tend to control the mapping
of XC labels onto LSPs. If a re-mapping is to occur for a
provisioning function, the management layer can
disseminate this information ahead of time such that when the re-
mapping happens, those ERs that use this label are aware immediately
of this change. This could be combined with standard LDP operating in
Downstream Unsolicited mode.
2.2.5 Source Routing
The implementation of the XC-Labels enables RToIP flows to be source
routed across a suitable path spanning multiple ASs.
An ER is able to build up route information by identifying the set of
next hops that reach a given destination. At the ingress to each AS,
the LSP that reaches a next hop is indicated by a single label. As
every such label can be added in sequence to an MPLS label stack and
appended to the front of a packet, the end-to-end path can be
resolved hop-by-hop as the packet traverses the route. That is, the
top-most label gives the first hop (and may be swapped as it traverse
that hop). As soon as that LSP has been traversed, the next label in
the stack, in this case an XC-label, is used to identify the next
hop.
A label stack can thus be defined at the network edge that comprises
N labels, where N is the number of ASs traversed edge-to-edge. The
top label is that of the first AS to be traversed. The 2nd to Nth
labels of the stack consist of the XC-labels that identify the
remainder of the packet's path across the network.
Alternatively, a single label could be used that is re-mapped at each
AS boundary.
Gibson Informational August 2001 10
draft-gibson-mpls-srcroute-00.txt Feb 2001
An edge router can then be aware of a number of alternative routes to
each of the other edge devices. Furthermore, this route information
can be passed up to the MBBs that control these edge devices. This
permits the management layer to be involved in the session
establishment process to select an optimal path as a part of the
admission control process. It also allows the management layer to
track LSP utilization in the network and perform load balancing and
other TE operations to avoid congestion.
2.2.6.1 Scalability
The solution outlined in this memo has a number of desirable
characteristics that enable it to scale. The source routing scheme
described in this memo would typically operate over edge to edge
routes that comprised no more than a collector-core-core-collector
configuration of ASs. In this regard, source routes of no deeper than
3 XC-labels plus a local LSP label need be stored.
Also, through using the MBB to define the routing policy at the ER,
it is possible to restrict the number of active edge to edge routes
that an ER stores in its loc_RIB. The full set of possible routes
can, however be stored in the Adj_RIB_In.
By adopting the Virtual Router methodology proposed in [RFC 2685], it
is possible to separate out these constrained XC-label Routing
Information Bases from those generally accessible to all normal
users.
2.2.6.2 Alternative Source Route discovery mechanisms
As an alternative to discovering the label defined source route using
the BGP techniques described above, the following mechanisms could
also be considered:
o BGP could be extended such that the AS_PATH attribute contains
an AS_SEQUENCE of (AS number, XC-label) pairs. This would be an
extension to the existing protocol whereby the XC label became a
routing element. Clearly any re-mapping of an XC label would
necessitate a BGP update if it changed the destination of a LSP
identified by that XC label. This is an artifact of tying the XC
label into the routing protocol.
o RSVP POLICY_ELEMENTS could be defined (see Appendix A) that can
exchange route information between MBBs, using a COPS-RSVP
interface from the ERs. This is an alternative piggyback method
to the first MPLS-BGP method and makes use of the fact that most
QoS requesting applications hand off the request for service to
RSVP.
Gibson Informational August 2001 11
draft-gibson-mpls-srcroute-00.txt Feb 2001
o The LDP Query mechanism defined in [QUERY] could be adopted and
used in a CR-LDP implementation of MPLS. This would permit ERs
to learn the set of labels that comprised an end-to-end link.
This solution still requires an XC creation mechanism. One might
use LDP operating in a Downstream Unsolicited mode to provide
this functionality.
2.3 Admission Control
Admission Control to the network is controlled by the MPLS Bandwidth
Brokers (MBBs) that sit at the edge of the network. The MBB is
responsible for controlling the mapping of RToIP flows onto edge to
edge routes at each ER it controls. It therefore plays a critical
role in satisfying the service level requested for the flow.
Session admission will typically occur in two stages: authorization
and session control. Guaranteed service network offerings are likely
to come at a premium to end-users. In most cases this will be through
a pre-agreed SLA with the service provider. In this case the MBB
needs to perform a check on the user's credentials before performing
any further message processing.
If the session setup signaling is from an unauthorised user, then the
session can be rejected. This may simply result in the MBB not
forwarding any session information, or it might prompt the explicit
signaling of a teardown message.
In this memo it is assumed that most traffic that requires an
explicit QoS level, will use RSVP to signal this requirement end to
end. In this case, the MBB acts like a COPS-RSVP PDP [COPS-RSVP], and
intercepts both Path and Resv messages. It therefore maintains a
COPS-RSVP interface to the ERs it controls.
The second stage of admission control also takes in the selection of
a suitable path for the new RToIP flow. Assuming continued service
guarantees are to be honoured, a new flow cannot be admitted where it
will cause degradation below an acceptable level to an already active
flow. The process of route selection is dealt with in the next
section. If no suitable path can be found to support the RToIP flow's
service requirements, this flow should not be admitted to the
network.
Admission Control may also encompass some form of billing and
accounting, depending on the user's SLA. This area is outside of the
scope of this memo but remains an area of high importance.
Gibson Informational August 2001 12
draft-gibson-mpls-srcroute-00.txt Feb 2001
2.4 Route Selection
At the edge of the network, the MBB has a view of the label stacks
available to traffic that originates at the ER(s) it controls. As it
has triggered the creation of the first-hop LSPs of each of those
label stacks, it has explicit knowledge of their available service
levels. What the MBB does not have an explicit view of, is the
available service levels of the LSPs that comprise the remainder of
the end to end path.
The problem of picking a complete end to end path can be solved by
restricting the route decision that an MBB has to make. An MBB has a
clear picture of the available bandwidth on the LSPs that emanate
from its local ERs. Using one of the techniques listed below, it is
also relatively simple to infer information about the availability of
LSPs referred to by XC labels.
o Use the BGP QoS feedback mechanism described in [Jacquenet].
This describes a QOS_NLRI attribute that describes both
available bandwidth and delay characteristics for a particular
route. This would permit ASBR peers to exchange QoS information
to aid route selection.
o [FEED] Describes TLVs that contain information about the
available bandwidth along an LSP that can be used to update the
routing table of an LSR. This information can be retrieved, for
example, by sending a Query message as per [QUERY]. This method
could simply be extended to have the fed-back information
pertain to the LSP that a XC-label identifies.
o A third method would be to define/identify a protocol that could
disseminate information between the MBBs in the management
layer. This could be similar to the protocol
identified to perform label stack dissemination. The work
currently ongoing in the Service Level Specification (SLS) wg
may lead to a suitable solution in this area.
o Finally, the RSVP extensions proposed in Appendix A could be
used to update path information. This could be included in
either new session signaling or in refresh information.
Whichever of these techniques is used, it is possible for the MBB to
learn service availability information about Border routers that sit
on the far side of the ASs that are connected to its home AS. In
other words, it is possible to learn information about downstream
routers.
There is a potential scalability issue with such techniques,
regarding the complexity of route information that has to be stored.
In order to ease this, imagine a scenario where the routing decision
Gibson Informational August 2001 13
draft-gibson-mpls-srcroute-00.txt Feb 2001
for the end to end path is divided in two at the ingress and egress
point of the network. This would reduce the problem (in the 4 AS
case) to picking two two-hop routes that intersect at the same ER.
Such ERs will be referred to as Pivot Points. An illustration of
where a Pivot Node sits in the network in relation to an MBB is shown
in Figure 3.
Figure 3 Role of Pivot Nodes
+-----+
|MBB 1| +-----+
+-----+ |MBB 2|
: +-----+
: /----\ /----\ /----\ /----\ :
: / \ / \+-----+/ \ / \ :
: | AS 1 |****| AS 2 |Pivot| AS 3 |****| AS 4 | :
: | | | |Node | | | | :
: * / \ /+-----+\ / \ * :
: ** \----/ \----/ \----/ \----/ ** :
+---*+ +*---+
|ER 1| |ER 2|
+----+ +----+
When negotiating an end to end path with an MBB that is 4 LSP hops
away, both MBBs are thus two hops away from a set of Pivot nodes that
might provide connectivity. (This can be determined, for example, by
determining the AS of the destination MBB and the consulting the
AS_PATH information from BGP.) With reference to Figure 3, a suitable
Pivot Node is illustrated at the border of both AS 2 and AS 3. It
should be noted that there might be a number of such suitable Pivot
Nodes, either at the intercept of other ASs that border AS1 and AS 4,
or if there are multiple intercepts between AS 2 and AS 3.
MBB 1 can thus determine the relevant Pivot Nodes through examination
of AS_PATH information from BGP.
2.4.1 Destination Service Notification Techniques
The use of such an architecture would require the knowledge at the
egress point of the connection (e.g. ER 2) of those routes that
terminate on it. Again, a number of options are open in this case.
Simplest of all is to assume that the sessions that are carried over
this network are symmetric in nature and that the LSP mesh is
similarly symmetric. Thus route determination decisions can be made
for the two half paths using the above listed feedback techniques and
storing the extended route information at the ERs.
Gibson Informational August 2001 14
draft-gibson-mpls-srcroute-00.txt Feb 2001
A second technique would be to invoke a feed-forward mechanism that
notifies downstream routers of the current utilization of the routes
towards them. This might easily be achieved through the use of
appropriate management packets into the RToIP streams that collate
route information.
If the ER-LSPs are established using RSVP-TE, is it possible to use
the Policy Element in Path refresh messages to include suitable
remaining service level information. Alternatively, if the RSVP
Aggregator/Deaggregator technique described in [RSVP-AGG] were
adopted, aggregate Path refresh messages could again be used to
update the service availability on each aggregate flow. Suitable
POLICY_ELEMENTS are defined in Appendix A.
This last method allows the MBB network visibility of the service
utilization of the underlying network. This also therefore permits
the MBBs to perform reconfiguration or SLA re-negotiation under
congestion conditions, either autonomously or under instruction from
the Policy management layer.
2.5 Application of VPN techniques
A further enhancement to the MPLS approach, is the use of Virtual
Network technology. This is especially relevant to deregulated
networks where operators lease bandwidth from an established operator
to run a set of services.
This technology provides the means by which a single network can be
divided into a number of separate networks over the same physical
topology. It therefore provides the means of handling RToIP traffic
separately from other network traffic. It also enables separation of
different traffic types onto logically separate networks. This
greatly aids the provision of service levels to a particular RToIP
flow.
A taxonomy of VPN schemes is performed in [RFC 2764], which presents,
amongst others, two MPLS specific solutions. These are the BGP-based
solution outlined in [RFC 2547] and a Virtual Router approach. Both
technologies provide a means of dividing a router into separate
logical entities at the network edge. This functionality is key if a
separate high QoS network is to be run on the same physical equipment
that normal (in terms of service level and requirements) Internet
traffic is routed over.
In order to separate the meshed LSP network into a service specific
network, a VPN methodology is used. In one scenario the PE router
functionality is split into a separate VR function(s) whose routing
table is populated with information pertaining to the LSP mesh. Or,
the BGP-based label distribution mechanism described in [RFC 2547] is
used to provide a logically separate network. In either case, the
Gibson Informational August 2001 15
draft-gibson-mpls-srcroute-00.txt Feb 2001
separate service networks are identified with a separate VPNID [RFC
2685] and the VPN Routing and Forwarding tables (VRF) are populated.
2.6 Inter-operator requirements
For this scheme to work seamlessly across multiple operator networks,
it is necessary for operators to share route availability information
with other operators. Clearly this is sensitive information, that
most operators would not be willing to freely share with their
competitors.
The XC-label scheme described in this memo appears to offer a
workaround to this situation. Instead of the particulars of a route
being advertised, an operator can announce the service availability
of an abstract path to a particular destination. This might be as
simple as a binary available/not available indication to an adjacent
SP or some more complex mechanism might be used. The advantage being
that the advertising SP can re-configure its network in response to
rise in demand for a particular service to a particular destination
seamlessly, providing it keeps the XC-label to destination mapping
consistent.
The ongoing work in SLS (Service Level Specification) might yield a
suitable advertisement mechanism.
2.7 Protection Strategies
The real-time services considered for this architecture will
typically require very fast recovery, on the order of tens of
milliseconds. In order to provide sufficiently fast restoration
using any recovery mechanisms, very fast fault detection is required,
i.e. through the use of the Fast Liveness Protocol (FLIP).
For non-local repair, very rapid propagation of Failure Indication
Signals (FIS) will also be necessary.
2.7.1 Protection across an AS
The LSPs across an AS between AS Border Routers may be protected,
using strategies consistent with the framework for MPLS-based
recovery [MPLS-REC]. Some combination of local repair or global
repair (end-to-end protection) may be appropriate.
For operation that is transparent to per-session control, protection
for these LSPs must provide equivalent recovery paths (no reduction
in capacity or quality of service) and must use the same AS Border
Routers.
Gibson Informational August 2001 16
draft-gibson-mpls-srcroute-00.txt Feb 2001
2.7.2 Protection of sessions
In some instances, LSPs across an AS may not be protected, or the
level of assurance provided by the protection on these tunnels may be
considered insufficient. In these cases, and also to protect against
the failures of AS Border Routers, recovery mechanisms may be
required for individual sessions.
End-to-end protection may be implemented by selecting a second end-
to-end path for a session and installing a backup mapping for the 6-
tuple filter at the ingress router. End-to-end protection could be
either 1+1 or 1:1. In the case of 1+1 protection, a mechanism to
select one output stream at the egress router is required, which may
require rapid downstream propagation of a fault indication signal
(FIS) from the point of failure. In the case of 1:1 protection,
rapid upstream propagation of a FIS from the point of failure to the
ingress router is needed.
Local repair may also be possible for some failures, by installing
appropriate cross-connects and backup label-mappings to redirect
traffic around a possible failure point. Note that the label stack
must be correct at the path merge point.
For protection paths to be effective, it must be possible to select
routes that are link and node disjoint. In addition to ensuring that
different AS Border routers and LSPs are selected by protection
paths, it is desirable to ensure that two LSPs through an AS do not
share common sources of failure. In some cases, this could be
achieved through the configuration of the LSP mesh, ensuring that all
LSPs in the VPRN in a given AS are fully fault-disjoint. Otherwise,
it may be important to provide information about the LSPs such as the
Shared Risk Link Group (SRLG) to the PDPs to use in path selection.
2.8 Applicability to RSVP aggregation
One of the efforts of the Integrated Services over Specific Link
Layers (ISSLL) working group is the area of RSVP aggregation [RSVP-
AGG]. This draft specifies how the total amount of state stored for
multiple RSVP initiated flows between two edge points of a core
network can be reduced by aggregating their state together.
Amongst other mechanisms involved is the determination of ingress
router, the "Aggregator", and the egress router, the "Deaggregator",
for these aggregate flows. Whilst determination of the former is
relatively trivial - - a Policy decision on where to apply flow
aggregation - - determination of the latter is more difficult.
It is proposed that the solution in this memo provides a good fit to
this RSVP aggregation model. Deaggregator selection is a matter of
performing the source routing described in this memo. As [RSVP-AGG]
Gibson Informational August 2001 17
draft-gibson-mpls-srcroute-00.txt Feb 2001
provides the mechanisms for determining what is an aggregate flow
message, these solutions dovetail well.
3.0 Future work
This draft is intended to set out a number of candidate solutions to
the Service levels problems set out in RFC 2990. It raises the
following work areas.
o Scaling of full mesh LSP configurations across an AS.
o Tunneling of service availability information in RSVP between
Bandwidth Brokers
Further work might also be carried out to see if the XC-Label
functionality defined in this draft could extend to be used in IGPs
such as OSPF or IS-IS.
4.0 Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
5.0 Security Considerations
This draft introduces a mechanism that controls entry into a
segregated network for real-time media flows, associated with session
service, that have been subjected to authentication. If the Service
Providers are trusted third parties then in the absence of failure or
misconfiguration, the real-time media flows cannot be subject to
malicious eavesdropping, though they may still be subject to lawful
interception.
Further, if the MPLS network is capable of honouring its resource
allocation to the configured LSPs then the core network is immune to
denial of service attacks. These security properties may be
compromised by the collector networks linking the Customer edge and
Provider Edge routers.
6.0 References
Gibson Informational August 2001 18
draft-gibson-mpls-srcroute-00.txt Feb 2001
[STANDARD] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[KEY-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC 2990] G. Huston, "Next Steps for the IP QoS Architecture", RFC
2990, November 2000.
[DIFF_MPLS] F. Le Faucher et al., "MPLS Support of Differentiated
Services", draft-ietf-mpls-diff-ext-07.txt, work in progress,
August 2000.
[Chadha] R. Chadha et al, "Policy Framework MPLS Information Model
for QoS and TE", draft-chadha-policy-mpls-te-01.txt, work in
progress, December 2000.
[LSR-MIB] C. Srinivasan, A. Viswanathan, T. Nadeau, "MPLS Label
Switch Router Management Information Base Using SMIv2", draft-
ietf-mpls-lsr-mib-07.txt, work in progress, January 2001.
[LDP-MIB] J. Cucchiara, H. Sjostrand, J. Luciani, "Definitions of
Managed Objects for the Multiprotocol Label Switching, Label
Distribution Protocol (LDP)", draft-ietf-mpls-ldp-mib-07.txt, work
in progress, August 2000.
[TE-MIB] C. Srinivasan, A. Viswanathan, T. Nadeau, "MPLS Traffic
Engineering Management Information Base Using SMIv2", draft-ietf-
mpls-te-mib-05.txt, work in progress, November 2000.
[COPS-MPLS] F. Reichmeyer, S. Wright, M. Gibson, "COPS Usage for
MPLS/Traffic Engineering", draft-franr-mpls-cops-00.txt, work in
progress, July 2000.
[RFC 3031] E. Rosen, A. Viswanathan & R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[BGP-MPLS] Y. Rekhter & E. Rosen, "Carrying Label Information in BGP-
4", draft-ietf-mpls-bgp4-mpls-05.txt, work in progress, January
2001.
[QUERY] P. Ashwood-Smith, A. Paraschiv, "MPLS LDP Query Message
Description", draft-ietf-mpls-lsp-query-01.txt, work in progress,
November 2000.
Gibson Informational August 2001 19
draft-gibson-mpls-srcroute-00.txt Feb 2001
[COPS-RSVP] S. Herzog et al., "COPS Usage for RSVP", RFC 2749,
January 2000.
[Jacquenet] C. Jacquenet, "Providing Quality of Service Indication by
the BGP-4 Protocol: the QOS_NLRI attribute", draft-jacquenet-qos-
nlri-01.txt, work in progress, November 2000.
[FEED] P. Ashwood-Smith et al., "Improving Topology Data Base
Accuracy with LSP Feedback", draft-ietf-mpls-te-feed-01.txt, work
in progress, December 2000.
[RFC 2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis,
"A Framework for IP Based Virtual Private Networks" RFC 2764,
February 2000.
[RFC 2547] E.Rosen, Y Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[RFC 2685] B. Fox, B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[MPLS-REC] V. Sharma et al., "Framework for MPLS-based Recovery",
draft-ietf-mpls-recovery-frmwrk-01.txt, work in progress, November
2000.
[RSVP-AGG] F. Baker et al., "Aggregation of RSVP or IPv4 and IPv6
Reservations", draft-ietf-issll-rsvp-aggr-02.txt, work in
progress, March 2000.
7.0 Acknowledgments
Thanks to Mark Cullum for his words on protection strategies, Roy
Mauger for the Security words and Dave Stacey for helpful review
comments and draft reconfiguration.
8.0 Author's Addresses
Mark Gibson
Nortel Networks
London Road, Harlow, Essex, UK
Email: mrg@nortelnetworks.com
Gibson Informational August 2001 20
draft-gibson-mpls-srcroute-00.txt Feb 2001
Appendix A
This Appendix sets out some extensions to the RSVP protocol.
Specifically it describes how the Path information encapsulation
described in the main body of this memo can be performed, using the
Policy Element in the Path and Resv messages. According to RFC 2750,
it is possible to exchange Policy information between adjacent Policy
aware RSVP routers using RSVP POLICY_DATA objects. That means two
adjacent PEPs can exchange information regarding the Policy
associated with the link between them. In this case, that Policy is
translated into the route information used to select the edge-to-edge
label stack.
RSVP uses the POLICY_DATA element to transfer Policy data between
PEPs (RSVP Policy enabled routers). This has the format shown in
Figure A.1. This element is part of both Path and Resv messages and
is used by adjacent RSVP nodes to exchange Policy information. It
starts with a length field, followed by an identifier that it is a
POLICY_DATA element. It contains two types of entries in an Option
List and a Policy Element List.
Fig A.1 POLICY_DATA element
+------------+------------+------------+------------+
| Length |POLICY_DATA | 1 |
+------------+------------+------------+------------+
| Data Offset |(0) reserved |
+------------+------------+------------+------------+
| |
// Option List //
| |
+---------------------------------------------------+
| |
// Policy Element List //
| |
+---------------------------------------------------+
Following the Options List in the POLICY_DATA element is the Policy
Element list. The format for this is the same used for the identity
representation described in RFC 2752 and can be seen in Figure A.2.
Gibson Informational August 2001 21
draft-gibson-mpls-srcroute-00.txt Feb 2001
Fig A.2 ROUTE_INFO POLICY_ELEMENT
+------------+------------+------------+------------+
| Length | P-Type = ROUTE_INFO |
+------------+------------+------------+------------+
| |
// Policy Information = Route Entries //
| |
+---------------------------------------------------+
The ROUTE_INFO element is the container for the route information to
be exchanged between the ERs. It starts with a length field, measured
in bytes followed by a P-Type that is set to ROUTE_INFO. It contains
a number of Route Entries whose format is shown in Figure A.3.
Fig A.3 Route Entry format
+------------+------------+------------+------------+
| Length | R-Type | Subtype |
+------------+------------+------------+------------+
| Value |
+------------+------------+------------+------------+
These Route Entries have a length field as first entry, followed by
an R-Type that defines the type of routing entry it is and a subtype
(currently undefined for all R-Types). The final part is the value
itself. The following R-Types are supported:
o IPV4_ADDR - IPv4 Address that uses the standard IPv4
address format in the Value field. This will be used to define
the address of the pivot node through which a route will be
selected.
o BANDWIDTH - This defines the bandwidth in bits per second
as a single 32-bit word. This gives up to 4.3 Gbps, however
subtypes could be defined in the future if this proved limiting.
Further subtypes could also be used to indicate that this was a
peak/mean/burst bandwidth.
o LABEL_STACK - This transports an n-label stack, when n =
Length/4. These labels are transmitted as the entire 32-bit shim
header. This is where the cross-connect labels would be
described.
This represents a initial list and other similar R-Types might be
defined to extend this list.
Gibson Informational August 2001 22
draft-gibson-mpls-srcroute-00.txt Feb 2001
Full Copyright Sta tement
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Gibson Informational August 2001 23
