CCAMP Working Group D. Papadimitriou (Alcatel)
Internet Draft M. Vigoureux (Alcatel)
Expiration Date: August 2005 K. Shiomoto (NTT)
D. Brungard (ATT)
J.L. Le Roux (FT)
February 2005
Generalized Multi-Protocol Label Switching (GMPLS) Protocol
Extensions for Multi-Region Networks (MRN)
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Most of the initial efforts on Generalized Multi-Protocol Label
Switching (GMPLS) have been related to environments hosting single
switching capability devices as such, the complexity raised by the
D.Papadimitriou et al. - Expires April 2005 [Page 1]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
control of such data planes is similar to the one expected in
classical IP/MPLS networks.
The present document analyses the various GMPLS signaling and routing
aspects when considering network environments consisting of multiple
switching capabilities as defined in RFC 3945.
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.
In addition the reader is assumed to be familiar with the concepts
developed in [GMPLS-ARCH], [RFC-3471], and [GMPLS-RTG] as well as
[HIER] and [BUNDLE].
1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) facilitates the
realization of seamless control integration of IP/MPLS networks with
SONET/SDH (see ANSI T1.105]/ITU-T G.707]) or Optical Transport
Networks (see ITU-T G.709). In particular, the applicability of GMPLS
to both packet/frame and circuit switching technologies (i.e. unified
control plane architecture) provides a unified control management
approach for both provisioning resources and restoration techniques.
One of the additional advantages driving the construction of a
unified Generalized Multi-Protocol Label Switching (GMPLS) control
plane is the desire to support multi LSP-region [HIER] routing and
Traffic Engineering (TE) capability. This would enable effective
network resource utilization of both the Packet/Layer2 LSP regions
and the Time Division Multiplexing (TDM) or Lambda LSP regions in
high capacity networks.
Vertical integration refers to the collaborative mechanisms within a
single control plane instance driving networks hosting multiple
switching capabilities. Such multi-switching capable networks are
referred to as Multi LSP-Region Networks or simply Multi-Region
Networks (MRN). A MRN is thus a vertically integrated network that
includes nodes hosting at least two different switching capabilities
that are controlled by a single instance of the GMPLS control plane.
The GMPLS protocol suite extensions proposed in this document follows
the requirements detailed in [MRN-REQ]. These extensions are proposed
in-line with the analysis of the GMPLS capabilities to accommodate
multiple switching capable networks as evaluated in [MRN-EVAL].
D.Papadimitriou et al. - Expires April 2005 [Page 2]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
2. Motivations
The rationales for investigating vertical integration (and thus
multi-region networks) in the GMPLS distributed control plane
context are detailed in [MRN-REQ]. This section determines the
corresponding motivations in terms of the GMPLS protocol suite:
- The maintenance of multiple instances of the control plane on
devices hosting more than one switching capability not only (and
obviously) increases the complexity of their interactions but also
increases the total amount of processing individual instances would
handle.
- The merge of both data and control plane addressing spaces helps
in avoiding multiple identification for the same object (a link for
instance or more generally any network resource), on the other hand
such aggregation does not impact the separation between the control
and the data plane.
- The collaboration between associated control planes (packet/framed
data planes) and non-associated control planes (SONET/SDH, G.709,
etc.) is facilitated due to the capability of hooking the
associated in-band signaling to the IP terminating interfaces of
the control plane.
- Resource management and policies to be applied at the edges of
such environment would be facilitated (less control to management
interactions) and more scalable (through the use of aggregated
information).
- Multi-region traffic engineering is facilitated as TE-links from
distinct regions are stored within the same TE Database
The next sections provide the operational aspects in terms of routing
and signaling for such environments as well as the extensions
required to instrument GMPLS to control such environments.
3. Routing over Forwarding Adjacencies
Forwarding Adjacencies (FAs) as described in [HIER] are a useful and
powerful tool for improving the scalability of GMPLS capable
networks. This concept enables the creation of a vertical (nested)
LSP Hierarchy.
3.1 Overview
A node may advertise an LSP as a TE link into the same OSPF/ISIS
instance. Such a TE link is referred to as a "Forwarding Adjacency"
(FA) link and the corresponding LSP to as a "Forwarding Adjacency
LSP", or simply FA-LSP. Since the advertised entity appears as a TE
link in OSPF/ISIS, both end-point nodes of the FA-LSP must belong to
the same OSPF area/ISIS level (thus constitute an intra-area
improvement of scalability). OSPF/ISIS floods the link-state
information about FAs just as it floods the information about any
D.Papadimitriou et al. - Expires April 2005 [Page 3]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
other TE Link. So, FA-LSPs may be advertised as TE links into the
same instance of OSPF/ISIS. This allows other nodes to use FAs as any
other TE Links for path computation purposes. As such, FA LSPs have
characteristics of both TE links and LSPs.
Following this approach, a TE Link provides a clear separation
between the routing adjacencies and the data plane bearer links (or
channels). Furthermore, as TE links have been extended to non-
adjacent devices by introducing the FA concept. This, in turn, allows
decreasing the number of control plane instances to control N LSP
regions (as defined in [LSP-HIER]). Last, the bundling of FA is also
defined in [BUNDLE] allowing for additional flexibility in
controlling large scale backbone networks.
FA-LSPs, if well tailored, provide additional scalability within a
routing plane instance (i.e. define virtual TE links without
increasing the number of routing adjacencies). Indeed, the use of FAs
provides a mechanism for improving bandwidth (or more generally any
resource) utilization when its dynamic allocation can be performed in
discrete units; it also enables aggregating forwarding state, and in
turn, reducing significantly the number of required labels as well as
the number of signaling sessions. Therefore, FAs may significantly
improve the scalability of GMPLS capable control planes, and allow
the creation of a TE-LSP hierarchy.
3.2 Scalability of Multi- Region Networks (with Single Switching Capable
Elements)
FAs allow avoiding the well-known O(N^2) problem at the control plane
level by using the mechanisms defined in [HIER] but requires a
specific policing at the LSP region boundaries in order to avoid full
meshes both at the data plane level and control plane level.
As specified in [HIER], it is expected that FAs will not be used for
establishing OSPF/ISIS peering relationship between the routers at
the ends of the adjacency thus clearly avoiding N square problem at
the control plane level. However, specific policies would be still
required to avoid a full mesh of FAs. A full mesh of FAs would lead,
at the control plane level, to a full mesh of signaling sessions
while, at the data plane, it would lead to poor resource utilization.
Avoiding full meshes can be accomplished by setting the default
metric of the FA to max[1, (the TE metric of the FA-LSP path - 1)] so
that it attracts traffic in preference to setting up a new LSP. Such
policing clearly states that FA-LSPs are driven by a most fit
approach: do not create new FA-LSPs as long as existing ones are not
filled up. The main issue with this approach is definitely related to
"what to advertise and originate at LSP region boundaries". For
instance, fully filled FA-LSPs should not be advertised (if
D.Papadimitriou et al. - Expires April 2005 [Page 4]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
preemption is not allowed), while, attracting traffic should be
provided in some coordinated manner in order to avoid sub-optimal FA-
LSP setup. Moreover, nothing precludes the maintenance of several
partially filled FA-LSPs that are kept unused indefinitely (even if
their metric is set optimally) in particular when the bandwidth of
the FA-LSP can not (due to its discrete bandwidth units) be exactly
set to the incoming LSP request.
Note: the latter suggests filtering of the corresponding LSAs at the
regions' boundaries. In OSPF, this can be accomplished by not
advertising the link as a regular LSA, but only as a TE opaque LSA
(see [RFC2370] and [RFC3630]).
3.3 Scalability of Multi-Region Networks (with Multi-Switching Capable
Elements)
The Shortest Path First (SPF) computation complexity is proportional
to L Log(N) where L is the number of links (here, more precisely TE
links) and N the number of address prefixes. As such, the full mesh
scalability issues can be solved in two ways either by improving the
computational capabilities of the (C-)SPF algorithms or simply by
keeping existing Log(N) complexity but then by improving
collaboration between data planes.
The former can be achieved for instance by using Fibonacci heaps
to O(L + N Log N) instead of O(L Log N) with binary heaps, and its
improvement with O(L Log Log(N)) complexity, which in turn, allows
for a number of TE links greater than 1E4 (versus ~1E3 with classical
implementations).
By considering M regions, over the same control plane topology and
without using any heuristics, one increases this complexity to M x L
(Log (M x N)). However, since TE Links can advertise multiple
Interface Switching Capabilities (ISC), the number of links can be
limited (by combination) by using specific topological maps referred
to as Virtual Network Topologies (VNT). The introduction of virtual
topological maps leads us to consider the concept of emulation of
data plane overlays [MAMLTE]. Therefore, the expectation here is to
reduce the overall computational complexity to L Log(M+1) x Log
(Log(M+1) x N) (note: with M = 1 it brings L Log(N)).
3.4 Emulating Virtual Topologies using FAs
According to ISC ordering [HIER], the following terminology can be
defined: FA-LSP(1) corresponds to FA link with PSC-1, FA-LSP(2) with
PSC-2, FA-LSP(3) with PSC-3, FA-LSP(4) with PSC-4, FA-LSP(5) with
L2SC, FA-LSP(6) with TDM, FA-LSP(7) with LSC and FA-LSP(8) with FSC.
FA-LSP(i) is routed over the FA-LSP(i+j) with j >= 1. In other words
D.Papadimitriou et al. - Expires April 2005 [Page 5]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
a set of FA-LSPs(i+j) with j fixed provides a Virtual Network
Topology (VNT) for routing FA-LSPs(i). The virtual network topology
offered by a set of FA-LSPs(i) is denoted by VNT(i) in this document.
The virtual network topology is changed by setting up and/or tearing
down one (or more) FA-LSP(i). The change of the VNT(i) affects the
routing of FA-LSPs(i-j). It is expected that boundary nodes of VNT(i)
will behave consistently with respect to any internal (LSP/link
recovery) or external (LSP/link provisioning) triggering event.
Below figure shows how the VNT is reconfigured by creating and/or
withdrawing FA-LSPs. P1, P2, and P3 are nodes in the PSC region
while T1, T2, and T3 are nodes in the TDM region.
-------------+ +--------------+ +----------
PSC | | TDM | | PSC
| | | |
----- P1 ------------ T1 ----------- P2 ---
| | | | |
------------+ | | | +----------
| T2 | +----------
| | | | PSC
| | | |
| T3 ----------- P3 ---
| | |
+--------------+ +----------
(a) Physical topology
P1 ----- P2 P1 P2
| | |
| | |
| | |
P3 ----- P3
(b) VNT 1 (c) VNT 2
By creating two FA-LSPs between P1 and P2, P2 and P3, the VNT 1 is
created. When the traffic demand between P1 and P2 decreases and
that between P1 and P3 increases, the FA-LSP between P1 and P2 is
destroyed and that between P1 and P3 is created. The VNT 1 is
reconfigured to the VNT 2.
3.5 FA Attributes Inheritance
Several FA-LSPs(i) between nodes over LSP region(i+1) are already
established, and several FA-LSPs(i-1) have been setup over this
topology and are partially filled up. One of the node of the FA-
LSP(i-1) region sees an incoming LSP request. It can be demonstrated
that the TE metric (in addition to the Maximum LSP Bandwidth and
D.Papadimitriou et al. - Expires April 2005 [Page 6]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
Unreserved Bandwidth see [GMPLS-RTG]) alone is not a sufficient
metric to compute the best path between these regions. This suggests
that the inheritance process over which the TE Metric of the FA is
not as straightforward as proposed in [HIER].
The best example is a packet LSP (PSC-1) to be multiplexed into PSC-
2 region that lies over an LSC region. The metric MUST not take only
into account packet boundaries interface features, properties and
traffic engineering attributes such as delay or bit-rate but also
for instance the distance over the LSP region that this LSP will
have to travel. As such, the TE Metric for the Lambda LSP (in this
example, FA-LSP(i+1)) must be at least defined as a combination of
the bit-rate and the distance, classically the bit-rate times the
distance with some weighting factors. The main issue from this
perspective is that joined Path TE Metric wouldn't in such a case
tackle simultaneously both packet and optical specifics.
This suggests the definition of more flexible TE Metric, at least the
definition of a TE Metric per ISC. Simply adjust the TE Metric to the
(TE Metric of the FA-LSP path - 1) is a valid approach between LSP
over the same region class (PSC-1, PSC-2, ... , PSC-N, for instance)
but not necessarily between PSC and LSC region.
Other TE attributes that need a specific processing during
inheritance are the Shared Risk Link Groups (SRLG), Resource
Class/Color (i.e. Administrative Groups) and Protection. The next
section will describe the specific TE attributes to be considered for
devices hosting at least two switching capabilities, in particular
the interface switching adaptation capabilities.
3.6 FA Abstraction for Recovery
In multi switching environments the inheritance of protection and
restoration related TE link attributes must also be considered.
1) Considering a 1:1 end-to-end LSP recovery scheme, two FA-LSPs may
be set up to form a single FA. To enhance the availability of the FA,
the primary and the secondary LSPs are set up. The primary LSP is
used to carry the normal traffic (see [TERM] and [E2E-RECOVERY]).
Once the failure occurs affecting the primary LSP, the normal traffic
is carried over the secondary LSP. From the routing perspective,
there is no topological change to carry the traffic. These two LSPs
should, therefore, be advertised within the scope of a single FA TE
link advertisement with link protection type of 1:1. This FA will be
processed by an upper LSP region as a span protected link.
2) Considering now a single FA-LSP, span protected over each link
(i.e. at the underlying LSP region).
D.Papadimitriou et al. - Expires April 2005 [Page 7]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
The question that arises is how should this span protected FA-LSP be
advertised in the IGP. A link protection type of 1:1 could also be
used for this advertisement but then, an upper region would have no
means to differentiate the two cases. However, these two recovery
schemes (end-to-end and span) have major differences in terms of
recovery delay and robustness [RECOVERY].
Therefore, abstraction and summarization must be performed when
advertising FA-LSPs as TE links (to an upper region) but using the
Link Protection Type flags and applying simple attribute inheritance
might not be sufficient to distinguish different recovery schemes.
4. Interface adaptation capability descriptor (IACD)
In an MRN environment, some LSR could contain, under the control of a
single GMPLS instance, multiple switching capabilities such as PSC
and TDM or PSC and Lambda Switching Capability (LSC).
These nodes, hosting multiple Interface Switching Capabilities (ISC),
are required to hold and advertise resource information on link
states and topology. They also may have to consider certain portions
of internal node resources to terminate hierarchical label switched
paths (LSPs), since circuit switch capable units such as TDMs, LSCs,
and FSCs require rigid resources. For example, a node with PSC+LSC
switching capability can switch a Lambda LSP but can never terminate
the Lambda LSP if there is no unused adaptation capability between
the LSC and the PSC switching capabilities.
Therefore, within multi-region networks, the advertisement of the so-
called adaptation capability to terminate LSPs (not the interface
capability since the latter can be inferred from the bandwidth
available for each switching capability) provides critical
information to take into account when performing multi-region path
computation. This concept enables a node to discriminate the remote
nodes (and thus allows their selection during path computation) with
respect to their adaptation capability e.g. to terminate LSPs at the
PSC or LSC level.
Hence, we introduce the idea of discriminating the (internal)
adaptation capability from the (interface) switching capability by
considering an interface adaptation capability descriptor.
4.1 Overview
Some nodes may host, under the control of a single GMPLS instance,
multiple Interface Switching Capabilities (ISC) such as PSC and
Time-Division-Multiplexing (TDM) or PSC and Lambda Switching
Capability (LSC) or Ethernet (L2SC) and TDM.
D.Papadimitriou et al. - Expires April 2005 [Page 8]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
For example, a L2SC+TDM switching capable node can deliver
connectivity for TDM LSPs but can never terminate the TDM LSP if
there is no unused adaptation capability left between the L2SC and
the TDM switching capabilities. Therefore, the advertisement of the
so-called adaptation capability to terminate LSPs provides the
critical information to take into account when performing multi-
region path computation. This concept enables a local node to
discriminate from remote nodes (and thus allows their selection
during path computation) with respect to their adaptation capability
e.g. to terminate TDM LSP at the L2SC level. Hence, the idea of
discriminating the (internal) adaptation capability from the
(interface) switching capability by considering an interface
adaptation capability descriptor has been introduced. The interface
adaptation capability descriptor (IACD) can be interpreted either as
the adaptation capability information from an incoming interface or
as the adaptation capability to an outgoing interface for a given
interface switching capability.
By introducing such an additional descriptor, by analogy to the
existing Interface Switching Capability Descriptor (ISCD) sub-TLV,
the local GMPLS control plane can swiftly determine which nodes can
terminate a certain encoding type of LSP and successfully establish
an LSP tunnel between endpoints terminating a particular SC. This
allows integrated devices to avoid the duplication of the switching
capacity at each SC by not requiring full capacity for interworking
between the SC. The IACD is thus an enabler for GMPLS application in
those integrated situations.
1) Number of Switching Capabilities:
The problem with the use of the interface switching capability
descriptor at the PSC+TDM+LSC node, is the shortage of LSP
termination capability information. For instance, a PSC+TDM+LSC node
provides only switching capability information by abstracting the
internal node capabilities. Therefore, remote nodes cannot accurately
determine which switching capability can be switched and/or
terminated at the PSC+TDM+LSC node. For such a node supporting LSC,
TDM and PSC switching capability, the determination of the
resource made available to cross for instance the LSC to PSC region
boundary (LSC -> PSC) may involve one of the following region cross-
over: LSC -> PSC and LSC -> TDM -> PSC.
Another example occurs when L2SC (Ethernet) switching can be adapted
in LAPS X.86 and GFP for instance before reaching the TDM switching
matrix. Similar circumstances can occur, if a switching fabric that
supports both PSC and L2SC functionalities is assembled with LSC
interfaces enabling "lambda" encoding. In the switching fabric, some
interfaces can terminate Lambda LSPs and perform frame (or cell)
D.Papadimitriou et al. - Expires April 2005 [Page 9]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
switching whilst other interfaces can terminate Lambda LSPs and
perform packet switching.
Thus, the interface switching capability descriptor provides the
information for the forwarding/switching) capability only. In order
for remote nodes to understand properly the termination capability of
the other nodes, additional information to the existing interface
switching capability descriptor is essential in achieving seamless
multi-region routing. In turn, adequate processing of this additional
information will allow the signaling of packet LSP set-up combined
with an automated triggering of new Lambda LSPs between nodes that do
not yet have a preferred Lambda LSP to carry the Packet LSP.
4.2 IACD Format
The IACD sub-TLV format is as follows. In IS-IS, this is a sub-TLV of
the Extended IS Reachability TLV (see [RFC 3784]) with type TBD. In
OSPF, it is defined as a sub-TLV of the Link TLV (see [RFC 3630]),
with type TBD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Capability-specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
- first Switching Capability (SC) field (byte 1): lower switching
capability (as
D.Papadimitriou et al. - Expires April 2005 [Page 10]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
defined for the existing ISC sub-TLV)
- first Encoding field (byte 2): as defined for the existing ISC
sub-TLV
- second SC value (byte 3): upper switching capability (new)
- second encoding value (byte 4): set to the encoding of the
available adaptation pool and to 0xFF when the corresponding SC
value has no access to the wire (i.e. there is no ISC sub-TLV for
this upper switching capability)
Multiple sub-TLVs may be present within a given TE Link TLV and the
bandwidth simply provides an indication of resources still available
to perform insertion/extraction for a given adaptation (pool
concept).
5. Multi-Region Signaling
Section 8.2 of [HIER] specifies that when an region boundary node
receives a Path message, the node determines whether it is at the
edge of an LSP region with respect to the ERO carried in the
message. If the node is at the edge of a region, it must then
determine the other edge of the region with respect to the ERO,
using the IGP database. The node then extracts from the ERO the
subsequence of hops from itself to the other end of the region.
The node then compares the subsequence of hops with all existing FA-
LSPs originated by the node:
- if a match is found, that FA-LSP has enough unreserved bandwidth
for the LSP being signaled, and the PID of the FA-LSP is
compatible with the PID of the LSP being signaled, the node uses
that FA-LSP as follows. The Path message for the original LSP is
sent to the egress of the FA-LSP. The PHOP in the message is the
address of the node at the head-end of the FA-LSP. Before sending
the Path message, the ERO in that message is adjusted by removing
the subsequence of the ERO that lies in the FA-LSP, and replacing
it with just the end point of the FA-LSP.
- if no existing FA-LSP is found, the node sets up a new FA-LSP.
That is, it initiates a new LSP setup just for the FA-LSP.
Applying this procedure, in a MRN environment MAY lead to setup one-
hop FA-LSPs between each node. Therefore, considering that the path
computation is able to take into account richness of information with
regard to the SC available on given nodes belonging to the path, it
is consistent to provide enough signaling information to indicate the
SC to be used and on over which link. Particularly, in case a TE
link has multiple SC advertised as part of its ISCD sub-TLVs, an ERO
does not allow selecting a particular SC.
Limiting modifications to existing the above RSVP-TE procedure is
required for this purpose. It is expected to provide this strict
D.Papadimitriou et al. - Expires April 2005 [Page 11]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
indication of SC through a new sub-object of the eXclude Route Object
(XRO). Such information can be specified by explicitly indicating
which SCs have to be excluded before initiating the procedure
described here above.
When a SC value has to be explicitly included (instead of excluding a
specific list of SC values) for a link part of the route followed by
the LSP, the same subobject with Type TBA, should be included as part
of the EXPLICIT ROUTE object (ERO). This subobject must follow the
numbered or unnumbered interface subobjects to which this subobject
refers. It is expected, when label subobject are following numbered
or unnumbered interface subobjects, that the label value is compliant
with the SC capability to be explicitly included.
This solves the ambiguous choice of SC that are potentially used
along a given path and give the possibility to optimize resource
usage on a multi-region basis.
5.1 SC Subobject Encoding
The contents of an EXCLUDE_ROUTE object defined in [XRO] are a
series of variable-length data items called subobjects. This
document defines the SC subobject of the XRO (Type TBD), its
encoding and processing.
Subobject Type TBD: Switching Capability
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Attribute | Switching Cap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
0 indicates that the attribute specified MUST be excluded
1 indicates that the attribute specified SHOULD be avoided
Attribute
0 reserved value
1 indicates that the specified SC should be excluded or
avoided with respect to the preceding numbered (Type 1 or
Type 2) or unnumbered interface (Type) subobject
6. Backward compatibility
TBD
D.Papadimitriou et al. - Expires April 2005 [Page 12]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
7. Security Considerations
In its current version, this memo does not introduce new security
consideration from the ones already detailed in the GMPLS protocol
suite.
8. References
8.1 Normative References
[BUNDLE] K.Kompella, et al., "Link Bundling in MPLS Traffic
Engineering", Work in Progress, draft-ietf-mpls-bundle-
04.txt.
[GMPLS-RTG] K.Kompella (Editor), Y. Rekhter (Editor) et al. "Routing
Extensions in Support of Generalized MPLS", Work in
Progress, draft-ietf-ccamp-gmpls-routing-09.txt.
[HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized
MPLS TE", Work in Progress, draft-ietf-mpls-lsp-
hierarchy-08.txt.
[RECOVERY] D.Papadimitriou et al. "Analysis of Generalized Multi-
Protocol Label Switching (GMPLS)-based Recovery
Mechanisms (including Protection and Restoration)," Work
in Progress, draft-ietf-ccamp-gmpls-recovery-analysis-
04.txt.
[INTER-AREA-AS] A.Ayyangar, et al., "Inter-area and Inter-AS MPLS
Traffic Engineering", Work in Progress, draft-vasseur-
ayyangar-ccamp-inter-area-AS-TE-00.txt
[L2SC-LSP] D.Papadimitriou, et al., "Generalized MPLS Signaling for
Layer-2 Label Switched Paths (LSP)", Work in Progress,
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt.
[MRN-EVAL] J.-L. Leroux et al., "Evaluation of existing GMPLS
Protocols against Multi Region Networks", Work in
Progress, draft-leroux-ccamp-mrn-gmpls-analysis-01.txt.
[MRN-REQ] K.Shiomoto et al., "Requirements for GMPLS-based Multi-
Region Networks (MRN)", Work in Progress, draft-
shiomoto-ccamp-gmpls-mrn-reqs-01.txt.
[RFC2119] Bradner, S., 'Key words for use in RFCs to indicate
requirements levels', RFC 2119, March 1997.
[RFC2370] R.Coltun, "The OSPF Opaque LSA Option", RFC 2370, July
1998.
D.Papadimitriou et al. - Expires April 2005 [Page 13]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
[RFC3471] L.Berger et al., "Generalized Multi-Protocol Label
Switching (GMPLS) - Signaling Functional Description",
RFC 3471, January 2003.
[RFC3630] D.Katz et al., "Traffic Engineering (TE) Extensions to
OSPF Version 2," RFC 3630, September 2003.
[RFC3667] Bradner, S., 'IETF Rights in Contributions', BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., 'Intellectual Property Rights in IETF
Technology', BCP 79, RFC 3668, February 2004.
[XRO] C.Y.Lee et al. "Exclude Routes - Extension to RSVP-TE,"
Work in progress, draft-ietf-ccamp-rsvp-te-exclude-
route-02.txt, July 2004.
8.2 Informative References
[MAMLTE] K.Shiomoto et al., "Multi-area multi-layer traffic
engineering using hierarchical LSPs in GMPLS networks",
Work in Progress, draft-shiomoto-multiarea-te-01.txt.
[MLRT] W.Imajuku et al., "Multilayer routing using multilayer
switch capable LSRs, Work in Progress, draft-imajuku-ml-
routing-02.txt.
Acknowledgments
The authors would like to thank Mr. Wataru Imajuku for the
discussions on adaptation between regions [MLRT].
Author's Addresses
Dimitri Papadimitriou (Alcatel)
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
E-mail: dimitri.papadimitriou@alcatel.be
Martin Vigoureux (Alcatel)
Route de Nozay,
91461 Marcoussis cedex, France
Phone: +33 (0)1 69 63 18 52
E-mail: martin.vigoureux@alcatel.fr
Kohei Shiomoto (NTT Network Service Systems Laboratories)
3-9-11 Midori-cho
D.Papadimitriou et al. - Expires April 2005 [Page 14]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
Musashino-shi, Tokyo 180-8585, Japan
Phone: +81 422 59 4402
E-mail: shiomoto.kohei@lab.ntt.co.jp
Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 420 1573
E-mail: dbrungard@att.com
Jean-Louis Le Roux (FTRD/DAC/LAN)
Avenue Pierre Marzin
22300 Lannion, France
Phone: +33 (0)2 96 05 30 20
E-mail:jean-louis.leroux@rd.francetelecom.com
Contributors
Eiji Oki (NTT Network Service Systems Laboratories)
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585, Japan
Phone : +81 422 59 3441
Email: oki.eiji@lab.ntt.co.jp
Ichiro Inoue(NTT Network Service Systems Laboratories)
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585, Japan
Phone : +81 422 59 6076
Email: ichiro.inoue@lab.ntt.co.jp
Emmanuel Dotaro (Alcatel)
Route de Nozay,
91461 Marcoussis cedex, France
Phone : +33 1 6963 4723
Email: emmanuel.dotaro@alcatel.fr
D.Papadimitriou et al. - Expires April 2005 [Page 15]
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt Feb. 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
D.Papadimitriou et al. - Expires April 2005 [Page 16]