draft-ietf-ccamp-gmpls-mln-eval-06.txt   rfc5339.txt 
Network Working Group J.L. Le Roux (Ed.) Network Working Group JL. Le Roux, Ed.
Internet Draft France Telecom Request for Comments: 5339 France Telecom
Category: Informational Category: Informational D. Papadimitriou, Ed.
Expires: January 2009 D. Papadimitriou (Ed.)
Alcatel-Lucent Alcatel-Lucent
Evaluation of Existing GMPLS Protocols Against Multi Layer September 2008
and Multi Region Networks (MLN/MRN)
draft-ietf-ccamp-gmpls-mln-eval-06.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of 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 Evaluation of Existing GMPLS Protocols
and may be updated, replaced, or obsoleted by other documents at any against Multi-Layer and Multi-Region Networks (MLN/MRN)
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 Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
This document provides an evaluation of Generalized Multi-Protocol This document provides an evaluation of Generalized Multiprotocol
Label Switching (GMPLS) protocols and mechanisms against the Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi-Layer Networks (MLN) and Multi-Region Networks requirements for Multi-Layer Networks (MLNs) and Multi-Region
(MRN). In addition, this document identifies areas where additional Networks (MRNs). In addition, this document identifies areas where
protocol extensions or procedures are needed to satisfy these additional protocol extensions or procedures are needed to satisfy
requirements, and provides guidelines for potential extensions. these requirements, and provides guidelines for potential extensions.
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.
Table of Contents Table of Contents
1. Introduction................................................3 1. Introduction ....................................................3
2. MLN/MRN Requirements Overview...............................4 1.1. Conventions Used in This Document ..........................4
3. Analysis....................................................5 2. MLN/MRN Requirements Overview ...................................4
3.1. Multi Layer Network Aspects.................................5 3. Analysis ........................................................5
3.1.1. Support for Virtual Network Topology Reconfiguration........5 3.1. Aspects of Multi-Layer Networks ............................5
3.1.1.1. Control of FA-LSPs Setup/Release..........................5 3.1.1. Support for Virtual Network Topology
3.1.1.2. Virtual TE-Links..........................................6 Reconfiguration .....................................5
3.1.1.3. Traffic Disruption Minimization During FA Release.........7 3.1.1.1. Control of FA-LSPs Setup/Release ...........5
3.1.1.4. Stability.................................................8 3.1.1.2. Virtual TE Links ...........................6
3.1.2. Support for FA-LSP Attributes Inheritance...................8 3.1.1.3. Traffic Disruption Minimization
3.1.3. FA-LSP Connectivity Verification............................8 during FA Release ..........................8
3.1.4. Scalability.................................................9 3.1.1.4. Stability ..................................8
3.1.5. Operations and Management of the MLN/MRN...................10 3.1.2. Support for FA-LSP Attribute Inheritance ............9
3.1.5.1. MIB Modules..............................................10 3.1.3. FA-LSP Connectivity Verification ....................9
3.1.5.2. OAM......................................................10 3.1.4. Scalability .........................................9
3.2. Specific Aspects for Multi-Region Networks.................11 3.1.5. Operations and Management of the MLN/MRN ...........10
3.2.1. Support for Multi-Region Signaling.........................11 3.1.5.1. MIB Modules ...............................10
3.2.2. Advertisement of Adjustment Capacities.....................12 3.1.5.2. OAM .......................................11
4. Evaluation Conclusion......................................15 3.2. Specific Aspects of Multi-Region Networks .................12
4.1. Traceability of Requirements...............................15 3.2.1. Support for Multi-Region Signaling .................12
5. Security Considerations....................................19 3.2.2. Advertisement of Adjustment Capacities .............13
6. IANA Considerations........................................19 4. Evaluation Conclusion ..........................................16
7. Acknowledgments............................................19 4.1. Traceability of Requirements ..............................16
8. References.................................................19 5. Security Considerations ........................................20
8.1. Normative References.......................................19 6. Acknowledgments ................................................20
8.2. Informative References.....................................20 7. References .....................................................21
9. Editors' Addresses.........................................21 7.1. Normative References ......................................21
10. Contributors' Addresses....................................22 7.2. Informative References ....................................21
11. Intellectual Property Statement............................22 8. Contributors' Addresses ........................................23
1. Introduction 1. Introduction
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching Generalized MPLS (GMPLS) extends MPLS to handle multiple switching
technologies: packet switching, layer-2 switching, TDM switching, technologies: packet switching, layer-2 switching, TDM (Time Division
wavelength switching, and fiber switching (see [RFC3945]). The Multiplexing) switching, wavelength switching, and fiber switching
Interface Switching Capability (ISC) concept is introduced for (see [RFC3945]). The Interface Switching Capability (ISC) concept is
these switching technologies and is designated as follows: PSC introduced for these switching technologies and is designated as
(Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM (Time follows: PSC (Packet Switch Capable), L2SC (Layer-2 Switch Capable),
Division Multiplex capable), LSC (Lambda Switch Capable), and FSC TDM capable, LSC (Lambda Switch Capable), and FSC (Fiber Switch
(Fiber Switch Capable). The representation, in a GMPLS control Capable). The representation, in a GMPLS control plane, of a
plane, of a switching technology domain is referred to as a region switching technology domain is referred to as a region [RFC4206]. A
[RFC4206]. A switching type describes the ability of a node to switching type describes the ability of a node to forward data of a
forward data of a particular data plane technology, and uniquely particular data plane technology, and uniquely identifies a network
identifies a network region. region.
A data plane switching layer describes a data plane switching A data plane switching layer describes a data plane switching
granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are
three different layers. [MLN-REQ] defines a Multi Layer Network three different layers. [RFC5212] defines a Multi-Layer Network
(MLN) to be a TE domain comprising multiple data plane switching (MLN) to be a Traffic Engineering (TE) domain comprising multiple
layers either of the same ISC (e.g. TDM) or different ISC (e.g. TDM data plane switching layers either of the same ISC (e.g., TDM) or
and PSC) and controlled by a single GMPLS control plane instance. different ISC (e.g., TDM and PSC) and controlled by a single GMPLS
[MLN-REQ] further defines a particular case of MLNs. A Multi Region control plane instance. [RFC5212] further defines a particular case
Network (MRN) is defined as a TE domain supporting at least two of MLNs. A Multi-Region Network (MRN) is defined as a TE domain
different switching types (e.g., PSC and TDM), either hosted on the supporting at least two different switching types (e.g., PSC and
same device or on different ones, and under the control of a single TDM), either hosted on the same device or on different ones, and
GMPLS control plane instance. under the control of a single GMPLS control plane instance.
The objectives of this document are to evaluate existing GMPLS The objectives of this document are to evaluate existing GMPLS
mechanisms and protocols ([RFC3945], [RFC4202], [RFC3471], mechanisms and protocols ([RFC3945], [RFC4202], [RFC3471], [RFC3473])
[RFC3473]) against the requirements for MLN and MRN, defined in against the requirements for MLNs and MRNs, defined in [RFC5212].
[MLN-REQ]. From this evaluation, we identify several areas where From this evaluation, we identify several areas where additional
additional protocol extensions and modifications are required to meet protocol extensions and modifications are required in order to meet
these requirements, and provide guidelines for potential extensions. these requirements, and we provide guidelines for potential
extensions.
A summary of MLN/MRN requirements is provided in section 2. Then A summary of MLN/MRN requirements is provided in Section 2. Then
section 3 evaluates for each of these requirements, whether current Section 3 evaluates whether current GMPLS protocols and mechanisms
GMPLS protocols and mechanisms meet the requirements. When the meet each of these requirements. When the requirements are not met
requirements are not met by existing protocols, the document by existing protocols, the document identifies whether the required
identifies whether the required mechanisms could rely on GMPLS mechanisms could rely on GMPLS protocols and procedure extensions, or
protocols and procedure extensions or whether it is entirely out of whether it is entirely out of the scope of GMPLS protocols.
the scope of GMPLS protocols.
Note that this document specifically addresses GMPLS control plane Note that this document specifically addresses GMPLS control plane
functionality for MLN/MRN in the context of a single administrative functionality for MLN/MRN in the context of a single administrative
control plane partition. Partitions of the control plane where control plane partition. Partitions of the control plane where
separate layers are under distinct administrative control are for separate layers are under distinct administrative control are for
future study. future study.
This document uses terminologies defined in [RFC3945], [RFC4206], and This document uses terminologies defined in [RFC3945], [RFC4206], and
[MLN-REQ]. [RFC5212].
1.1. 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 [RFC2119].
2. MLN/MRN Requirements Overview 2. MLN/MRN Requirements Overview
Section 5 of [MLN-REQ] lists a set of functional requirements for Section 5 of [RFC5212] lists a set of functional requirements for
Multi Layer/Region Networks (MLN/MRN). These requirements are Multi-Layer/Region Networks (MLN/MRN). These requirements are
summarized below, and a mapping with sub-sections of [MLN-REQ] is summarized below, and a mapping with sub-sections of [RFC5212] is
provided. provided.
Here is the list of requirements that apply to MLN (and thus to MRN): Here is the list of requirements that apply to MLN (and thus to MRN):
- Support for robust Virtual Network Topology (VNT) reconfiguration. - Support for robust Virtual Network Topology (VNT) reconfiguration.
This implies the following requirements: This implies the following requirements:
- Optimal control of Forwarding Adjacency LSP (FA-LSP) setup and - Optimal control of Forwarding Adjacency Label Switched Path
release (Section 5.8.1 of [MLN-REQ]); (FA-LSP) setup and release (Section 5.8.1 of [RFC5212]);
- Support for virtual TE-links (Section 5.8.2 of [MLN-REQ]); - Support for virtual TE links (Section 5.8.2 of [RFC5212]);
- Traffic Disruption minimization during FA-LSP release (Section - Minimization of traffic disruption during FA-LSP release
5.5 of [MLN-REQ]); (Section 5.5 of [RFC5212]);
- Stability (Section 5.4 of [MLN-REQ]); - Stability (Section 5.4 of [RFC5212]);
- Support for FA-LSP attributes inheritance (Section 5.6 of - Support for FA-LSP attribute inheritance (Section 5.6 of
[MLN-REQ]); [RFC5212]);
- Support for FA-LSP data plane connectivity verification - Support for FA-LSP data plane connectivity verification (Section
(Section 5.9 of [MLN-REQ]); 5.9 of [RFC5212]);
- MLN Scalability (section 5.3 of [MLN-REQ]); - MLN Scalability (Section 5.3 of [RFC5212]);
- MLN OAM (section 5.10 of [MLN-REQ]); - MLN Operations and Management (OAM) (Section 5.10 of [RFC5212]);
Here is the list of requirements that apply to MRN only: Here is the list of requirements that apply to MRN only:
- Support for Multi-Region signaling (section 5.7 of [MLN-REQ]); - Support for Multi-Region signaling (Section 5.7 of [RFC5212]);
- Advertisement of the adjustment capacity (section 5.2 of - Advertisement of the adjustment capacity (Section 5.2 of
[MLN-REQ]); [RFC5212]);
3. Analysis 3. Analysis
3.1. Multi Layer Network Aspects 3.1. Aspects of Multi-Layer Networks
3.1.1. Support for Virtual Network Topology Reconfiguration 3.1.1. Support for Virtual Network Topology Reconfiguration
A set of lower-layer FA-LSPs provides a Virtual Network Topology A set of lower-layer FA-LSPs provides a Virtual Network Topology
(VNT) to the upper-layer [MLN-REQ]. By reconfiguring the VNT (FA-LSP (VNT) to the upper-layer [RFC5212]. By reconfiguring the VNT (FA-LSP
setup/release) according to traffic demands between source and setup/release) according to traffic demands between source and
destination node pairs within a layer, network performance factors destination node pairs within a layer, network performance factors
such as maximum link utilization and residual capacity of the network (such as maximum link utilization and residual capacity of the
can be optimized. Such optimal VNT reconfiguration implies several network) can be optimized. Such optimal VNT reconfiguration implies
mechanisms that are analyzed in the following sections. several mechanisms that are analyzed in the following sections.
Note that the VNT approach is just one possible approach to perform Note that the VNT approach is just one possible approach to
inter-layer Traffic Engineering. performing inter-layer Traffic Engineering.
3.1.1.1. Control of FA-LSPs Setup/Release 3.1.1.1. Control of FA-LSPs Setup/Release
In a Multi-Layer Network, FA-LSPs are created, modified, released In a Multi-Layer Network, FA-LSPs are created, modified, and released
periodically according to the change of incoming traffic demands from periodically according to the change of incoming traffic demands from
the upper layer. the upper layer.
This implies a TE mechanism that takes into account the demands This implies a TE mechanism that takes into account the demands
matrix, the TE topology and potentially the current VNT, in order to matrix, the TE topology, and potentially the current VNT, in order to
compute and setup a new VNT. compute and setup a new VNT.
Several functional building blocks are required to support such TE Several functional building blocks are required to support such a TE
mechanism: mechanism:
- Discovery of TE topology and available resources. - Discovery of TE topology and available resources.
- Collection of upper layer traffic demands. - Collection of upper-layer traffic demands.
- Policing and scheduling of VNT resources with regard to traffic - Policing and scheduling of VNT resources with regard to traffic
demands and usage (that is, decision to setup/release FA-LSPs). The demands and usage (that is, decision to setup/release FA-LSPs).
functional component in charge of this function is called a VNT The functional component in charge of this function is called a VNT
Manager (VNTM) [PCE-INTER]. Manager (VNTM) [PCE-INTER].
- VNT Paths Computation according to TE topology, and potentially - VNT Path Computation according to TE topology, potentially taking
taking into account the old (existing) VNT to minimize changes. The into account the old (existing) VNT in order to minimize changes.
Functional component in charge of VNT computation may be The functional component in charge of VNT computation may be
distributed on network elements or may be performed on an external distributed on network elements or may be performed on an external
element (such as a Path Computation Element (PCE), [RFC4655]). element (such as a Path Computation Element (PCE), [RFC4655]).
- FA-LSP setup/release. - FA-LSP setup/release.
GMPLS routing protocols provide TE topology discovery. GMPLS routing protocols provide TE topology discovery. GMPLS
GMPLS signaling protocols allow setting up/releasing FA-LSPs. signaling protocols allow setting up/releasing FA-LSPs.
VNTM functions (resources policing/scheduling, decision to VNTM functions (resources policing/scheduling, decision to
setup/release FA-LSPs, FA-LSP configuration) are out of the scope of setup/release FA-LSPs, FA-LSP configuration) are out of the scope of
GMPLS protocols. Such functionalities can be achieved directly on GMPLS protocols. Such functionalities can be achieved directly on
layer border LSRs, or through one or more external tools. When an layer-border Label Switching Routers (LSRs), or through one or more
external tool is used, an interface is required between the VNTM and external tools. When an external tool is used, an interface is
the network elements so as to setup/release FA-LSPs. This could use required between the VNTM and the network elements so as to
standard management interfaces such as [RFC4802]. setup/release FA-LSPs. This could use standard management interfaces
such as [RFC4802].
The set of traffic demands of the upper layer is required for the The set of traffic demands of the upper layer is required for the VNT
VNT Manager to take decisions to setup/release FA-LSPs. Such Manager to take decisions to setup/release FA-LSPs. Such traffic
traffic demands include satisfied demands, for which one or more demands include satisfied demands, for which one or more upper-layer
upper layer LSP have been successfully setup, as well as unsatisfied LSP have been successfully setup, as well as unsatisfied demands and
demands and future demands, for which no upper layer LSP has been future demands, for which no upper layer LSP has been setup yet. The
setup yet. The collection of such information is beyond the scope of collection of such information is beyond the scope of GMPLS
GMPLS protocols. Note that it may be partially inferred from protocols. Note that it may be partially inferred from parameters
parameters carried in GMPLS signaling or advertised in GMPLS carried in GMPLS signaling or advertised in GMPLS routing.
routing.
Finally, the computation of FA-LSPs that form the VNT can be Finally, the computation of FA-LSPs that form the VNT can be
performed directly on layer border LSRs or on an external element performed directly on layer-border LSRs or on an external element
(such as a Path Computation Element (PCE), [RFC4655]), and this is (such as a Path Computation Element (PCE), [RFC4655]), and this is
independent of the location of the VNTM. independent of the location of the VNTM.
Hence, to summarize, no GMPLS protocol extensions are required to Hence, to summarize, no GMPLS protocol extensions are required to
control FA-LSP setup/release. control FA-LSP setup/release.
3.1.1.2. Virtual TE-Links 3.1.1.2. Virtual TE Links
A Virtual TE-link is a TE-link between two upper layer nodes that is A virtual TE link is a TE link between two upper layer nodes that is
not actually associated with a fully provisioned FA-LSP in a lower not actually associated with a fully provisioned FA-LSP in a lower
layer. A Virtual TE-link represents the potentiality to setup an FA- layer. A virtual TE link represents the potentiality to setup an
LSP in the lower layer to support the TE-link that has been FA-LSP in the lower layer to support the TE link that has been
advertised. A Virtual TE-link is advertised as any TE-link, following advertised. A virtual TE link is advertised as any TE link,
the rules in [RFC4206] defined for fully provisioned TE-links. In following the rules in [RFC4206] defined for fully provisioned TE
particular, the flooding scope of a Virtual TE-link is within an IGP links. In particular, the flooding scope of a virtual TE link is
area, as is the case for any TE-link. within an IGP area, as is the case for any TE link.
If an upper-layer LSP attempts (through a signaling message) to make If an upper-layer LSP attempts (through a signaling message) to make
use of a Virtual TE-link, the underlying FA-LSP is immediately use of a virtual TE link, the underlying FA-LSP is immediately
signaled and provisioned (provided there are available resources in signaled and provisioned (provided there are available resources in
the lower layer) in the process known as triggered signaling. the lower layer) in the process known as triggered signaling.
The use of Virtual TE-links has two main advantages: The use of virtual TE links has two main advantages:
- Flexibility: allows the computation of an LSP path using TE-links - Flexibility: allows the computation of an LSP path using TE links
without needing to take into account the actual provisioning status without needing to take into account the actual provisioning status
of the corresponding FA-LSP in the lower layer; of the corresponding FA-LSP in the lower layer;
- Stability: allows stability of TE-links in the upper layer, while - Stability: allows stability of TE links in the upper layer, while
avoiding wastage of bandwidth in the lower layer, as data plane avoiding wastage of bandwidth in the lower layer, as data plane
connections are not established until they are actually needed. connections are not established until they are actually needed.
Virtual TE-links are setup/deleted/modified dynamically, according to Virtual TE links are setup/deleted/modified dynamically, according to
the change of the (forecast) traffic demand, operator's policies for the change of the (forecast) traffic demand, operator's policies for
capacity utilization, and the available resources in the lower layer. capacity utilization, and the available resources in the lower layer.
The support of Virtual TE-links requires two main building blocks: The support of virtual TE links requires two main building blocks:
- A TE mechanism for dynamic modification of Virtual TE-link - A TE mechanism for dynamic modification of virtual TE link
Topology; topology;
- A signaling mechanism for the dynamic setup and deletion of virtual - A signaling mechanism for the dynamic setup and deletion of virtual
TE-links. Setting up a virtual TE-link requires a signaling TE links. Setting up a virtual TE link requires a signaling
mechanism allowing an end-to-end association between Virtual mechanism that allows an end-to-end association between virtual TE
TE-link end points so as to exchange link identifiers as well as link end points with the purpose of exchanging link identifiers as
some TE parameters. well as some TE parameters.
The TE mechanism responsible for triggering/policing dynamic The TE mechanism responsible for triggering/policing dynamic
modification of Virtual TE-links is out of the scope of GMPLS modification of virtual TE links is out of the scope of GMPLS
protocols. protocols.
Current GMPLS signaling does not allow setting up and releasing Current GMPLS signaling does not allow setting up and releasing
Virtual TE-links. Hence GMPLS signaling must be extended to support virtual TE links. Hence, GMPLS signaling must be extended to support
Virtual TE-links. virtual TE links.
We can distinguish two options for setting up Virtual TE-links: We can distinguish two options for setting up virtual TE links:
- The Soft FA approach that consists of setting up the FA-LSP in the - The Soft FA approach consists of setting up the FA-LSP in the
control plane without actually activating cross connections in the control plane without actually activating cross connections in the
data plane. On the one hand, this requires state maintenance on all data plane. On the one hand, this requires state maintenance on
transit LSRs (N square issue), but on the other hand this may allow all transit LSRs (N square issue), but on the other hand, this may
for some admission control. Indeed, when a soft-FA is activated, allow for some admission control. Indeed, when a Soft FA is
the resources may be no longer available for use by other soft-FAs activated, the resources may no longer be available for use by
that have common links. These soft-FA will be dynamically released other Soft FAs that have common links. These Soft FA will be
and corresponding virtual TE-links are deleted. The soft-FA LSPs dynamically released, and corresponding virtual TE links will be
may be setup using procedures similar to those described in deleted. The Soft FA LSPs may be setup using procedures similar to
[RFC4872] for setting up secondary LSPs. those described in [RFC4872] for setting up secondary LSPs.
- The remote association approach that simply consists of exchanging - The remote association approach simply consists of exchanging
virtual TE-links IDs and parameters directly between TE-link end virtual TE link IDs and parameters directly between TE link end
points. This does not require state maintenance on transit LSRs, points. This does not require state maintenance on transit LSRs,
but reduces admission control capabilities. Such an association but reduces admission control capabilities. Such an association
between Virtual TE-link end-points may rely on extensions to the between virtual TE link end points may rely on extensions to the
RSVP-TE ASON Call procedure ([RFC4974]). Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
Automatically Switched Optical Network (ASON) call procedure
[RFC4974].
Note that the support of Virtual TE-links does not require any GMPLS Note that the support of virtual TE links does not require any GMPLS
routing extension. routing extension.
3.1.1.3. Traffic Disruption Minimization During FA Release 3.1.1.3. Traffic Disruption Minimization during FA Release
Before deleting a given FA-LSP, all nested LSPs have to be rerouted Before deleting a given FA-LSP, all nested LSPs have to be rerouted
and removed from the FA-LSP to avoid traffic disruption. and removed from the FA-LSP to avoid traffic disruption. The
The mechanisms required here are similar to those required for mechanisms required here are similar to those required for graceful
graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism deletion of a TE link. A Graceful TE link deletion mechanism allows
allows for the deletion of a TE-link without disrupting traffic of for the deletion of a TE link without disrupting traffic of TE-LSPs
TE-LSPs that were using the TE-link. that were using the TE link.
Hence, GMPLS routing and/or signaling extensions are required Hence, GMPLS routing and/or signaling extensions are required to
to support graceful deletion of TE-links. This may utilize the support graceful deletion of TE links. This may utilize the
procedures described in [GR-SHUT]: A transit LSR notifies a head-end procedures described in [GR-SHUT]: a transit LSR notifies a head-end
LSR that a TE-link along the path of a LSP is going to be torn down, LSR that a TE link along the path of an LSP is going to be torn down,
and also withdraws the bandwidth on the TE-link so that it is not and also withdraws the bandwidth on the TE link so that it is not
used for new LSPs. used for new LSPs.
3.1.1.4. Stability 3.1.1.4. Stability
The stability of upper-layer LSP may be impaired if the VNT undergoes The stability of upper-layer LSP may be impaired if the VNT undergoes
frequent changes. In this context robustness of the VNT is defined as frequent changes. In this context, robustness of the VNT is defined
the capability to smooth the impact of these changes and avoid their as the capability to smooth the impact of these changes and avoid
subsequent propagation. their subsequent propagation.
Guaranteeing VNT stability is out of the scope of GMPLS protocols and Guaranteeing VNT stability is out of the scope of GMPLS protocols and
relies entirely on the capability of the TE and VNT management relies entirely on the capability of the TE and VNT management
algorithms to minimize routing perturbations. This requires that the algorithms to minimize routing perturbations. This requires that the
algorithms take into account the old VNT when computing a new VNT, algorithms take into account the old VNT when computing a new VNT,
and try to minimize the perturbation. and try to minimize the perturbation.
Note that a full mesh of lower-layer LSPs may be created between Note that a full mesh of lower-layer LSPs may be created between
every pair of border nodes between the upper and lower layers. The every pair of border nodes between the upper and lower layers. The
merit of a full mesh of lower-layer LSPs is that it provides merit of a full mesh of lower-layer LSPs is that it provides
stability to the upper layer routing. That is, forwarding table used stability to the upper-layer routing. That is, the forwarding table
in the upper layer is not impacted if the VNT undergoes changes. used in the upper layer is not impacted if the VNT undergoes changes.
Further, there is always full reachability and immediate access to Further, there is always full reachability and immediate access to
bandwidth to support LSPs in the upper layer. But it also has bandwidth to support LSPs in the upper layer. But it also has
significant drawbacks, since it requires the maintenance of n^2 RSVP- significant drawbacks, since it requires the maintenance of n^2
TE sessions, where n is the number of border nodes, which may be RSVP-TE sessions (where n is the number of border nodes), which may
quite CPU and memory consuming (scalability impact). Also this may be quite CPU- and memory-consuming (scalability impact). Also, this
lead to significant bandwidth wastage. Note that the use of virtual may lead to significant bandwidth wastage. Note that the use of
TE-links solves the bandwidth wastage issue, and may reduce the virtual TE links solves the bandwidth wastage issue, and may reduce
control plane overload. the control plane overload.
3.1.2. Support for FA-LSP Attributes Inheritance 3.1.2. Support for FA-LSP Attribute Inheritance
When a FA TE Link is advertised, its parameters are inherited from When an FA TE Link is advertised, its parameters are inherited from
the parameters of the FA-LSP, and specific inheritance rules are the parameters of the FA-LSP, and specific inheritance rules are
applied. applied.
This relies on local procedures and policies and is out of the scope This relies on local procedures and policies and is out of the scope
of GMPLS protocols. Note that this requires that both head-end and of GMPLS protocols. Note that this requires that both head-end and
tail-end of the FA-LSP are driven by same policies. tail-end of the FA-LSP are driven by same policies.
3.1.3. FA-LSP Connectivity Verification 3.1.3. FA-LSP Connectivity Verification
Once fully provisioned, FA-LSP liveliness may be achieved by Once fully provisioned, FA-LSP liveliness may be achieved by
verifying its data plane connectivity. verifying its data plane connectivity.
FA-LSP connectivity verification relies on technology specific FA-LSP connectivity verification relies on technology-specific
mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using BFD; mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using
etc.) as for any other LSP. Hence this requirement is out of the Bidrectional Forwarding Detection (BFD); etc.) as for any other LSP.
scope of GMPLS protocols. Hence, this requirement is out of the scope of GMPLS protocols.
The GMPLS protocols should provide mechanisms for the coordination of
data link verification in the upper-layer network where data links
are lower-layer LSPs.
The GMPLS protocols should provide mechanisms for the coordination
of data link verification in the upper layer network where data
links are lower layer LSPs.
o GMPLS signaling allows an LSP to be put into 'test' mode o GMPLS signaling allows an LSP to be put into 'test' mode
[RFC3473]. [RFC3473].
o The link Management Protocol [RFC4204] is a targeted protocol and o The Link Management Protocol [RFC4204] is a targeted protocol
can be run end-to-end across lower-layer LSPs. and can be run end-to-end across lower-layer LSPs.
o Coordination of testing procedures in different layers is an o Coordination of testing procedures in different layers is an
operational matter. operational matter.
3.1.4. Scalability 3.1.4. Scalability
As discussed in [MLN-REQ]), MRN/MLN routing mechanisms must be As discussed in [RFC5212]), MRN/MLN routing mechanisms must be
designed to scale well with an increase of any of the following: designed to scale well with an increase of any of the following:
- Number of nodes - Number of nodes
- Number of TE-links (including FA-LSPs) - Number of TE links (including FA-LSPs)
- Number of LSPs - Number of LSPs
- Number of regions and layers - Number of regions and layers
- Number of ISCDs per TE-link. - Number of Interface Switching Capability Descriptors (ISCDs) per
TE link.
GMPLS routing provides the necessary advertisement functions and is GMPLS routing provides the necessary advertisement functions and is
based on IETF-designed IGPs. These are known to scale relatively well based on IETF-designed IGPs. These are known to scale relatively
with the number of nodes and links. Where there are multiple regions well with the number of nodes and links. Where there are multiple
or layers there are two possibilities. regions or layers, there are two possibilities.
1. If a single routing instance distributes information about 1. If a single routing instance distributes information about
multiple network layers, the effect is no more than to increase the multiple network layers, the effect is no more than to increase
number of nodes and links in the network. the number of nodes and links in the network.
2. If the MLN is fully integrated (i.e., constructed from hybrid 2. If the MLN is fully integrated (i.e., constructed from hybrid
nodes), there is an increase in the number of nodes and links nodes), there is an increase in the number of nodes and links
as just mentioned, and also a potential increase in the amount (as just mentioned), and also a potential increase in the
of ISCD information advertised per link. This is a relatively amount of ISCD information advertised per link. This is a
small amount of information (e.g., 36 bytes in OSPF [RFC4203]) relatively small amount of information (e.g., 36 bytes in OSPF
per switching type, and each interface is unlikely to have more [RFC4203]) per switching type, and each interface is unlikely
than two or three switching types. to have more than two or three switching types.
The number of LSPs in a lower layer, advertised as TE-links may The number of LSPs in a lower layer that are advertised as TE links
impact the scaling of the routing protocol. A full mesh of FA-LSPs in may impact the scaling of the routing protocol. A full mesh of FA-
the lower layer would lead to n^2 TE-links where n is the number of LSPs in the lower layer would lead to n^2 TE links, where n is the
layer border LSRs. This must be taken into consideration in the VNT number of layer-border LSRs. This must be taken into consideration
management process. This is an operational matter beyond the scope of in the VNT management process. This is an operational matter beyond
GMPLS protocols. the scope of GMPLS protocols.
As regards the scalability of GMPLS signaling, a full mesh of LSPs in Since it requires the maintenance of n^2 RSVP-TE sessions (which may
the lower layer may impact the salability since it requires the be quite CPU- and memory-consuming), a full mesh of LSPs in the lower
maintenance of n^2 RSVP-TE sessions, which may be quite CPU and layer may impact the scalability of GMPLS signaling. The use of
memory consuming. The use of virtual TE-links may reduce the control virtual TE links may reduce the control plane overload (see Section
plane overload (see section 3.1.1.2). 3.1.1.2).
3.1.5. Operations and Management of the MLN/MRN 3.1.5. Operations and Management of the MLN/MRN
[MLN-REQ] identifies various requirements for effective management [RFC5212] identifies various requirements for effective management
and operation of the MLN. Some features already exist within the and operation of the MLN. Some features already exist within the
GMPLS protocol set, some more are under development, and some GMPLS protocol set, some more are under development, and some
requirements are not currently addressed and will need new requirements are not currently addressed and will need new
development work in order to support them. development work in order to support them.
3.1.5.1. MIB Modules 3.1.5.1. MIB Modules
MIB modules have been developed to model and control GMPLS switches MIB modules have been developed to model and control GMPLS switches
[RFC4803] and to control and report on the operation of the signaling [RFC4803] and to control and report on the operation of the signaling
protocol [RFC4802]. These may be successfully used to manage the protocol [RFC4802]. These may be successfully used to manage the
operation of a single instance of the control plane protocols that operation of a single instance of the control plane protocols that
operate across multiple layers. operate across multiple layers.
[RFC4220] provides a MIB module for managing TE links, and this may [RFC4220] provides a MIB module for managing TE links, and this may
be particularly useful in the context of the MLN as LSPs in the lower be particularly useful in the context of the MLN because LSPs in the
layers are made available as TE links in the higher layer. lower layers are made available as TE links in the higher layer.
The traffic engineering database provides a repository for all The traffic engineering database provides a repository for all
information about the existence and current status of TE links within information about the existence and current status of TE links within
a network. This information is typically flooded by the routing a network. This information is typically flooded by the routing
protocol operating within the network, and is used when LSP routes protocol operating within the network, and is used when LSP routes
are computed. [TED-MIB] provides a way to inspect the TED to view the are computed. [TED-MIB] provides a way to inspect the TED to view
TE links at the different layers of the MLN. the TE links at the different layers of the MLN.
As observed in [MLN-REQ], although it would be possible to manage the As observed in [RFC5212], although it would be possible to manage the
MLN using only the existing MIB modules, a further MIB module could MLN using only the existing MIB modules, a further MIB module could
be produced to coordinate the management of separate network layers be produced to coordinate the management of separate network layers
in order to construct a single MLN entity. Such a MIB module would in order to construct a single MLN entity. Such a MIB module would
effectively link together entries in the MIB modules already effectively link together entries in the MIB modules already
referenced. referenced.
3.1.5.2. OAM 3.1.5.2. OAM
At the time of writing, the development of OAM tools for GMPLS At the time of writing, the development of OAM tools for GMPLS
networks is at an early stage. GMPLS OAM requirements are addressed networks is at an early stage. GMPLS OAM requirements are addressed
skipping to change at page 10, line 50 skipping to change at page 11, line 34
At the time of writing, the development of OAM tools for GMPLS At the time of writing, the development of OAM tools for GMPLS
networks is at an early stage. GMPLS OAM requirements are addressed networks is at an early stage. GMPLS OAM requirements are addressed
in [GMPLS-OAM]. in [GMPLS-OAM].
In general, the lower layer network technologies contain their own In general, the lower layer network technologies contain their own
technology-specific OAM processes (for example, SDH/SONET, Ethernet, technology-specific OAM processes (for example, SDH/SONET, Ethernet,
and MPLS). In these cases, it is not necessary to develop additional and MPLS). In these cases, it is not necessary to develop additional
OAM processes, but GMPLS procedures may be desirable to coordinate OAM processes, but GMPLS procedures may be desirable to coordinate
the operation and configuration of these OAM processes. the operation and configuration of these OAM processes.
[ETH-OAM] describes some early ideas for this function, but more work [ETH-OAM] describes some early ideas for this function, but more work
is required to generalize the technique to be applicable to all is required to generalize the technique to be applicable to all
technologies and to MLN. In particular OAM function operating within technologies and to MLN. In particular, an OAM function operating
a server layer must be controllable from the client layer, and client within a server layer must be controllable from the client layer, and
layer control plane mechanisms must map and enable OAM in the server client layer control plane mechanisms must map and enable OAM in the
layer. server layer.
Where a GMPLS-controlled technology does not contain its own OAM Where a GMPLS-controlled technology does not contain its own OAM
procedures, this is usually because the technology cannot support procedures, this is usually because the technology cannot support
in-band OAM (for example, WDM networks). In these cases, there is in-band OAM (for example, Wavelength Division Multiplexing (WDM)
very little that a control plane can add to the OAM function since networks). In these cases, there is very little that a control plane
the presence of a control plane cannot make any difference to the can add to the OAM function since the presence of a control plane
physical characteristics of the data plane. However, the existing cannot make any difference to the physical characteristics of the
GMPLS protocol suite does provide a set of tools that can help to data plane. However, the existing GMPLS protocol suite does provide
verify the data plane through control plane. These tools are equally a set of tools that can help to verify the data plane through the
applicable to network technologies that do contain their own OAM. control plane. These tools are equally applicable to network
technologies that do contain their own OAM.
- Route recording is available through the GMPLS signaling protocol - Route recording is available through the GMPLS signaling protocol
[RFC3473] making it possible to check the route reported by the [RFC3473], making it possible to check the route reported by the
control plane against the expected route. This mechanism also control plane against the expected route. This mechanism also
includes the ability to record and report the interfaces and labels includes the ability to record and report the interfaces and labels
used for the LSP at each hop of its path. used for the LSP at each hop of its path.
- The status of TE links is flooded by the GMPLS routing protocols - The status of TE links is flooded by the GMPLS routing protocols
[RFC4203] and [RFC4205] making it possible to detect changes in the [RFC4203] and [RFC4205] making it possible to detect changes in the
available resources in the network as an LSP is set up. available resources in the network as an LSP is set up.
- The GMPLS signaling protocol [RFC3473] provides a technique to - The GMPLS signaling protocol [RFC3473] provides a technique to
place an LSP into a "test" mode so that end-to-end characteristics place an LSP into a "test" mode so that end-to-end characteristics
skipping to change at page 11, line 41 skipping to change at page 12, line 31
- GMPLS signaling [RFC3473] provides a Notify message that can be - GMPLS signaling [RFC3473] provides a Notify message that can be
used to report faults and issues across the network. The message used to report faults and issues across the network. The message
includes scaling features to allow one message to report the includes scaling features to allow one message to report the
failure of multiple LSPs. failure of multiple LSPs.
- Extensions to GMPLS signaling [RFC4783] enable alarm information to - Extensions to GMPLS signaling [RFC4783] enable alarm information to
be collected and distributed along the path of an LSP for more easy be collected and distributed along the path of an LSP for more easy
coordination and correlation. coordination and correlation.
3.2. Specific Aspects for Multi-Region Networks 3.2. Specific Aspects of Multi-Region Networks
3.2.1. Support for Multi-Region Signaling 3.2.1. Support for Multi-Region Signaling
There are actually several cases where a transit node could choose There are actually several cases where a transit node could choose
between multiple SCs to be used for a lower region FA-LSP: between multiple Switching Capabilities (SCs) to be used for a
lower-region FA-LSP:
- Explicit Route Object (ERO) expansion with loose hops: The transit - Explicit Route Object (ERO) expansion with loose hops: The transit
node has to expand the path, and may have to select among a set of node has to expand the path, and may have to select among a set of
lower region SCs. lower-region SCs.
- Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of - Multi-SC TE link: When the ERO of an FA LSP, included in the ERO of
an upper region LSP, comprises a multi-SC TE-link, the region an upper-region LSP, comprises a multi-SC TE link, the region
border node has to select among these SCs. border node has to select among these SCs.
Existing GMPLS signaling procedures do not allow solving this Existing GMPLS signaling procedures do not allow solving this
ambiguous choice of SC that may be used along a given path. ambiguous choice of the SC that may be used along a given path.
Hence an extension to GMPLS signaling has to be defined to indicate Hence, an extension to GMPLS signaling has to be defined to indicate
the SC(s) that can be used and the SC(s) that cannot be used along the SC(s) that can be used and the SC(s) that cannot be used along
the path. the path.
3.2.2. Advertisement of Adjustment Capacities 3.2.2. Advertisement of Adjustment Capacities
In the MRN context, nodes supporting more than one switching In the MRN context, nodes supporting more than one switching
capability on at least one interface are called Hybrid nodes ([MLN- capability on at least one interface are called hybrid nodes
REQ]). Conceptually, hybrid nodes can be viewed as containing at [RFC5212]. Conceptually, hybrid nodes can be viewed as containing at
least two distinct switching elements interconnected by internal least two distinct switching elements interconnected by internal
links which provide adjustment between the supported switching links that provide adjustment between the supported switching
capabilities. These internal links have finite capacities and must be capabilities. These internal links have finite capacities and must
taken into account when computing the path of a multi-region TE-LSP. be taken into account when computing the path of a multi-region TE-
The advertisement of the adjustment capacities is required as it LSP. The advertisement of the adjustment capacities is required, as
provides critical information when performing multi-region path it provides critical information when performing multi-region path
computation. computation.
The term adjustment capacity refers to the property of a hybrid node The term "adjustment capacity" refers to the property of a hybrid
to interconnect different switching capabilities it provides through node to interconnect different switching capabilities it provides
its external interfaces [MLN-REQ]. This information allows path through its external interfaces [RFC5212]. This information allows
computation to select an end-to-end multi-region path that includes path computation to select an end-to-end multi-region path that
links of different switching capabilities that are joined by LSRs includes links of different switching capabilities that are joined by
that can adapt the signal between the links. LSRs that can adapt the signal between the links.
Figure 1a below shows an example of hybrid node. The hybrid node has Figure 1a below shows an example of a hybrid node. The hybrid node
two switching elements (matrices), which support here TDM and PSC has two switching elements (matrices), which support TDM and PSC
switching respectively. The node has two PSC and TDM ports (port1 and switching, respectively. The node has two PSC and TDM ports (Port1
port2 respectively). It also has an internal link connecting the two and Port2, respectively). It also has an internal link connecting
switching elements. the two switching elements.
The two switching elements are internally interconnected in such a The two switching elements are internally interconnected in such a
way that it is possible to terminate some of the resources of the TDM way that it is possible to terminate some of the resources of the TDM
port 2 and provide through them adjustment for PSC traffic, Port2; also, they can provide adjustment of PSC traffic that is
received/sent over the internal PSC interface (#b). Two ways are received/sent over the internal PSC interface (#b). Two ways are
possible to set up PSC LSPs (port 1 or port 2). Available resources possible to set up PSC LSPs (Port1 or Port2). Available resources
advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover advertisement (e.g., Unreserved and Min/Max LSP Bandwidth) should
both ways. cover both ways.
Network element Network element
............................. .............................
: -------- : : -------- :
PSC : | PSC | : PSC : | PSC | :
Port1-------------<->---|#a | : Port1-------------<->---|#a | :
: +--<->---|#b | : : +--<->---|#b | :
: | -------- : : | -------- :
: | ---------- : : | ---------- :
TDM : +--<->--|#c TDM | : TDM : +--<->--|#c TDM | :
Port2 ------------<->--|#d | : Port2 ------------<->--|#d | :
: ---------- : : ---------- :
:............................ :............................
Figure 1a. Hybrid node. Figure 1a. Hybrid node.
Port 1 and Port 2 can be grouped together thanks to internal DWDM, to Port1 and Port2 can be grouped together thanks to internal Dense
result in a single interface: Link 1. This is illustrated in figure Wavelength Division Multiplexing (DWDM), to result in a single
1b below. interface: Link1. This is illustrated in Figure 1b below.
Network element Network element
............................. .............................
: -------- : : -------- :
: | PSC | : : | PSC | :
: | | : : | | :
: --|#a | : : --|#a | :
: | | #b | : : | | #b | :
: | -------- : : | -------- :
: | | : : | | :
: | ---------- : : | ---------- :
: /| | | #c | : : /| | | #c | :
: | |-- | | : : | |-- | | :
Link1 ========| | | TDM | : Link1 ========| | | TDM | :
: | |----|#d | : : | |----|#d | :
: \| ---------- : : \| ---------- :
:............................ :............................
Figure 1b. Hybrid node. Figure 1b. Hybrid node.
Let's assume that all interfaces are STM16 (with VC4-16c capable Let's assume that all interfaces are STM16 (with VC4-16c capable as
as Max LSP bandwidth). After, setting up several PSC LSPs via port #a Max LSP bandwidth). After setting up several PSC LSPs via port #a
and setting up and terminating several TDM LSPs via port #d and port and setting up and terminating several TDM LSPs via port #d and port
#b, there is only 155 Mb capacities still available on port #b. #b, a capacity of only 155 Mb is still available on port #b.
However a 622 Mb capacity remains on port #a and VC4-5c capacity on However, a 622 Mb capacity remains on port #a, and VC4-5c capacity
port #d. remains on port #d.
When computing the path for a new VC4-4c TDM LSP, one must know, that When computing the path for a new VC4-4c TDM LSP, one must know that
this node cannot terminate this LSP, as there is only 155Mb still this node cannot terminate this LSP, as there is only a 155 Mb
available for TDM-PSC adjustment. Hence the TDM-PSC adjustment capacity still available for TDM-PSC adjustment. Hence, the TDM-PSC
capacity must be advertised. adjustment capacity must be advertised.
With current GMPLS routing [RFC4202] this advertisement is possible With current GMPLS routing [RFC4202], this advertisement is possible
if link bundling is not used and if two TE-links are advertised for if link bundling is not used and if two TE links are advertised for
link1: Link1.
We would have the following TE-link advertisements: We would have the following TE link advertisements:
TE-link 1 (port 1): TE link 1 (Port1):
- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb - ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb
- Unreserved bandwidth = 622Mb. - Unreserved bandwidth = 622Mb.
TE-Link 2 (port 2): TE link 2 (Port2):
- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb, - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,
- Unreserved bandwidth (equivalent): 777 Mb. - Unreserved bandwidth (equivalent): 777 Mb.
The ISCD 2 in TE-link 2 represents actually the TDM-PSC adjustment The ISCD #2 in TE link 2 actually represents the TDM-PSC adjustment
capacity. capacity.
However if for obvious scalability reasons link bundling is done then However, if for obvious scalability reasons, link bundling is done,
the adjustment capacity information is lost with current GMPLS then the adjustment capacity information is lost with current GMPLS
routing, as we have the following TE-link advertisement: routing, as we have the following TE link advertisement:
TE-link 1 (port 1 + port 2): TE link 1 (Port1 + Port2):
- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb, - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,
- Unreserved bandwidth (equivalent): 1399 Mb. - Unreserved bandwidth (equivalent): 1399 Mb.
With such TE-link advertisement an element computing the path of a With such a TE link advertisement, an element computing the path of a
VC4-4c LSP cannot know that this LSP cannot be terminated on the VC4-4c LSP cannot know that this LSP cannot be terminated on the
node. node.
Thus current GMPLS routing can support the advertisement of the Thus, current GMPLS routing can support the advertisement of the
adjustment capacities but this precludes performing link bundling and adjustment capacities, but this precludes performing link bundling
thus faces significant scalability limitations. and thus faces significant scalability limitations.
Hence, GMPLS routing must be extended to meet this requirement. This Hence, GMPLS routing must be extended to meet this requirement. This
could rely on the advertisement of the adjustment capacities as a new could rely on the advertisement of the adjustment capacities as a new
TE link attribute (that would complement the Interface Switching TE link attribute (that would complement the Interface Switching
Capability Descriptor TE-link attribute). Capability Descriptor TE link attribute).
Note: Multiple ISCDs MAY be associated to a single switching Note: Multiple ISCDs MAY be associated with a single switching
capability. This can be performed to provide e.g. for TDM interfaces capability. This can be performed to provide (e.g., for TDM
the Min/Max LSP Bandwidth associated to each (set of) layer for that interfaces) the Min/Max LSP Bandwidth associated to each layer (or
switching capability. As an example, an interface associated to TDM set of layers) for that switching capability. For example, an
switching capability and supporting VC-12 and VC-4 switching, can be interface associated to TDM switching capability and supporting VC-12
associated one ISCD sub-TLV or two ISCD sub-TLVs. In the first case, and VC-4 switching can be associated to one ISCD sub-TLV or two ISCD
the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to sub-TLVs. In the first case, the Min LSP Bandwidth is set to VC-12
VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and and the Max LSP Bandwidth to VC-4. In the second case, the Min LSP
the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the Bandwidth is set to VC-12 and the Max LSP Bandwidth to VC-12, in the
Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4, first ISCD sub-TLV; and the Min LSP Bandwidth is set to VC-4 and the
in the second ISCD sub-TLV. Hence, in the first case, as long as the Max LSP Bandwidth to VC-4, in the second ISCD sub-TLV. Hence, in the
Min LSP Bandwidth is set to VC-12 (and not VC-4) and in the second first case, as long as the Min LSP Bandwidth is set to VC-12 (and not
case, as long as the first ISCD sub-TLV is advertised there is VC-4), and in the second case, as long as the first ISCD sub-TLV is
sufficient capacity across that interface to setup a VC-12 LSP. advertised, there is sufficient capacity across that interface to
setup a VC-12 LSP.
4. Evaluation Conclusion 4. Evaluation Conclusion
Most of the required MLN/MRN functions will rely on mechanisms and Most of the required MLN/MRN functions will rely on mechanisms and
procedures that are out of the scope of the GMPLS protocols, and thus procedures that are out of the scope of the GMPLS protocols, and thus
do not require any GMPLS protocol extensions. They will rely on local do not require any GMPLS protocol extensions. They will rely on
procedures and policies, and on specific TE mechanisms and local procedures and policies, and on specific TE mechanisms and
algorithms. algorithms.
As regards Virtual Network Topology (VNT) computation and As regards Virtual Network Topology (VNT) computation and
reconfiguration, specific TE mechanisms need to be defined, but these reconfiguration, specific TE mechanisms need to be defined, but these
mechanisms are out of the scope of GMPLS protocols. mechanisms are out of the scope of GMPLS protocols.
Six areas for extensions of GMPLS protocols and procedures have been Six areas for extensions of GMPLS protocols and procedures have been
identified: identified:
- GMPLS signaling extension for the setup/deletion of the virtual - GMPLS signaling extension for the setup/deletion of the virtual TE
TE-links; links;
- GMPLS signaling extension for graceful TE-link deletion; - GMPLS signaling extension for graceful TE link deletion;
- GMPLS signaling extension for constrained multi-region signaling - GMPLS signaling extension for constrained multi-region signaling
(SC inclusion/exclusion); (SC inclusion/exclusion);
- GMPLS routing extension for the advertisement of the adjustment - GMPLS routing extension for the advertisement of the adjustment
capacities of hybrid nodes. capacities of hybrid nodes.
- A MIB module for coordination of other MIB modules being operated - A MIB module for coordination of other MIB modules being operated
in separate layers. in separate layers.
- GMPLS signaling extensions for the control and configuration of - GMPLS signaling extensions for the control and configuration of
technology-specific OAM processes. technology-specific OAM processes.
4.1. Traceability of Requirements 4.1. Traceability of Requirements
This section provides a brief cross-reference to the requirements set This section provides a brief cross-reference to the requirements set
out in [MLN-REQ] so that it is possible to verify that all of the out in [RFC5212] so that it is possible to verify that all of the
requirements listed in that document have been examined in this requirements listed in that document have been examined in this
document. document.
- Path computation mechanism should be able to compute paths and - Path computation mechanism should be able to compute paths and
handle topologies consisting of any combination of (simplex) nodes handle topologies consisting of any combination of (simplex) nodes
([MLN-REQ], Section 5.1). ([RFC5212], Section 5.1).
o Path computation mechanisms are beyond the scope of protocol o Path computation mechanisms are beyond the scope of protocol
specifications, and out of scope for this document. specifications, and out of scope for this document.
- A hybrid node should maintain resources on its internal links - A hybrid node should maintain resources on its internal links
([MLN-REQ], Section 5.2). ([RFC5212], Section 5.2).
o This is an implementation requirement and is beyond the scope of o This is an implementation requirement and is beyond the scope of
protocol specifications, and out of scope for this document. protocol specifications, and it is out of scope for this document.
- Path computation mechanisms should be prepared to use the - Path computation mechanisms should be prepared to use the
availability of termination/adjustment resources as a constraint in availability of termination/adjustment resources as a constraint in
path computation ([MLN-REQ], Section 5.2). path computation ([RFC5212], Section 5.2).
o Path computation mechanisms are beyond the scope of protocol o Path computation mechanisms are beyond the scope of protocol
specifications, and out of scope for this document. specifications, and out of scope for this document.
- The advertisement of a node's ability to terminate lower-region - The advertisement of a node's ability to terminate lower-region
LSPs and to forward traffic in the upper-region (adjustment LSPs and to forward traffic in the upper-region (adjustment
capability) is required ([MLN-REQ], Section 5.2). capability) is required ([RFC5212], Section 5.2).
o See Section 3.2.2 of this document. o See Section 3.2.2 of this document.
- The path computation mechanism should support the coexistence of - The path computation mechanism should support the coexistence of
upper-layer links directly connected to upper-layer switching upper-layer links directly connected to upper-layer switching
elements, and upper-layer links connected through internal links elements, and upper-layer links connected through internal links
between upper-layer and lower-layer switching elements ([MLN-REQ], between upper-layer and lower-layer switching elements ([RFC5212],
Section 5.2). Section 5.2).
o Path computation mechanisms are beyond the scope of protocol o Path computation mechanisms are beyond the scope of protocol
specifications, and out of scope for this document. specifications, and out of scope for this document.
- MRN/MLN routing mechanisms must be designed to scale well with an - MRN/MLN routing mechanisms must be designed to scale well with an
increase of any of the following: increase of any of the following:
- Number of nodes - Number of nodes
- Number of TE-links (including FA-LSPs) - Number of TE links (including FA-LSPs)
- Number of LSPs - Number of LSPs
- Number of regions and layers - Number of regions and layers
- Number of ISCDs per TE-link. - Number of ISCDs per TE link.
([MLN-REQ], Section 5.3). ([RFC5212], Section 5.3).
o See Section 3.1.4 of this document. o See Section 3.1.4 of this document.
- Design of the routing protocols must not prevent TE information - Design of the routing protocols must not prevent TE information
filtering based on ISCDs, ([MLN-REQ], Section 5.3). filtering based on ISCDs ([RFC5212], Section 5.3).
o All advertised information carries the ISCD and so a receiving o All advertised information carries the ISCD, and so a receiving
node may filter as required. node may filter as required.
- The path computation mechanism and the signaling protocol should be - The path computation mechanism and the signaling protocol should be
able to operate on partial TE information, ([MLN-REQ], Section able to operate on partial TE information, ([RFC5212], Section
5.3). 5.3).
o Path computation mechanisms are beyond the scope of protocol o Path computation mechanisms are beyond the scope of protocol
specifications, and out of scope for this document. specifications, and out of scope for this document.
- Protocol mechanisms must be provided to enable creation, deletion, - Protocol mechanisms must be provided to enable creation, deletion,
and modification of LSPs triggered through operational actions, and modification of LSPs triggered through operational actions
([MLN-REQ], Section 5.4). ([RFC5212], Section 5.4).
o Such mechanisms are standard in GMPLS signaling [RFC3473]. o Such mechanisms are standard in GMPLS signaling [RFC3473].
- Protocol mechanisms should be provided to enable similar functions - Protocol mechanisms should be provided to enable similar functions
triggered by adjacent layers, ([MLN-REQ], Section 5.4). triggered by adjacent layers ([RFC5212], Section 5.4).
o Such mechanisms are standard in GMPLS signaling [RFC3473]. o Such mechanisms are standard in GMPLS signaling [RFC3473].
- Protocol mechanisms may be provided to enable adaptation to changes - Protocol mechanisms may be provided to enable adaptation to changes
such as traffic demand, topology, and network failures. Routing such as traffic demand, topology, and network failures. Routing
robustness should be traded with adaptability of those changes, robustness should be traded with adaptability of those changes
([MLN-REQ], Section 5.4). ([RFC5212], Section 5.4).
o See section 3.1.1 of this document. o See Section 3.1.1 of this document.
- Reconfiguration of the VNT must be as non-disruptive as possible - Reconfiguration of the VNT must be as non-disruptive as possible
and must be under the control of policy configured by the operator, and must be under the control of policy configured by the operator
([MLN-REQ], Section 5.5). ([RFC5212], Section 5.5).
o See Section 3.1.1.3 of this document o See Section 3.1.1.3 of this document
- Parameters of a TE link in an upper should be inherited from the - Parameters of a TE link in an upper layer should be inherited from
parameters of the lower-layer LSP that provides the TE-link, based the parameters of the lower-layer LSP that provides the TE link,
on polices configured by the operator, ([MLN-REQ], Section 5.6). based on polices configured by the operator ([RFC5212], Section
5.6).
o See Section 3.1.2 of this document. o See Section 3.1.2 of this document.
- The upper-layer signaling request may contain an ERO that includes - The upper-layer signaling request may contain an ERO that includes
only hops in the upper layer, ([MLN-REQ], Section 5.7). only hops in the upper layer ([RFC5212], Section 5.7).
o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1. o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1.
- The upper-layer signaling request may contain an ERO specifying the - The upper-layer signaling request may contain an ERO specifying the
lower layer FA-LSP route, ([MLN-REQ], Section 5.7). lower layer FA-LSP route ([RFC5212], Section 5.7).
o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1. o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1.
- As part of the re-optimization of the MLN, it must be possible to - As part of the re-optimization of the MLN, it must be possible to
reroute a lower-layer FA-LSP while keeping interface identifiers of reroute a lower-layer FA-LSP while keeping interface identifiers of
the corresponding TE links unchanged and causing only minimal the corresponding TE links unchanged and causing only minimal
disruption to higher-layer traffic, ([MLN-REQ], Section 5.8.1). disruption to higher-layer traffic ([RFC5212], Section 5.8.1).
o See Section 3.1.1.3. o See Section 3.1.1.3.
- The solution must include measures to protect against network - The solution must include measures to protect against network
destabilization caused by the rapid setup and teardown of lower- destabilization caused by the rapid setup and tear-down of lower-
layer LSPs as traffic demand varies near a threshold, ([MLN-REQ], layer LSPs, as traffic demand varies near a threshold ([RFC5212],
Sections 5.8.1 and 5.8.2). Sections 5.8.1 and 5.8.2).
o See Section 3.1.1.4. o See Section 3.1.1.4.
- Signaling of lower-layer LSPs should include a mechanism to rapidly - Signaling of lower-layer LSPs should include a mechanism to rapidly
advertise the LSP as a TE link in the upper layer, and to advertise the LSP as a TE link in the upper layer, and to
coordinate into which routing instances the TE link should be coordinate into which routing instances the TE link should be
advertised, ([MLN-REQ], Section 5.8.1). advertised ([RFC5212], Section 5.8.1).
o This is provided by [RFC4206] and enhanced by [HIER-BIS]. See o This is provided by [RFC4206] and enhanced by [HIER-BIS]. See
also Section 3.1.1.2. also Section 3.1.1.2.
- If an upper-layer LSP is set up making use of a virtual TE-Link, - If an upper-layer LSP is set up making use of a virtual TE link,
the underlying LSP must immediately be signaled in the lower layer, the underlying LSP must immediately be signaled in the lower layer
([MLN-REQ], Section 5.8.2). ([RFC5212], Section 5.8.2).
o See Section 3.1.1.2. o See Section 3.1.1.2.
- The solution should provide operations to facilitate the build-up - The solution should provide operations to facilitate the build-up
of virtual TE-links, taking into account the forecast upper-layer of virtual TE links, taking into account the forecast upper-layer
traffic demand and available resource in the lower-layer, traffic demand, and available resource in the lower layer
([MLN-REQ], Section 5.8.2). ([RFC5212], Section 5.8.2).
o See Section 3.1.1.2 of this document. o See Section 3.1.1.2 of this document.
- The GMPLS protocols should provide mechanisms for the coordination - The GMPLS protocols should provide mechanisms for the coordination
of data link verification in the upper layer network where data of data link verification in the upper-layer network where data
links are lower layer LSPs, ([MLN-REQ], Section 5.9). links are lower layer LSPs ([RFC5212], Section 5.9).
o See Section 3.1.3 of this document. o See Section 3.1.3 of this document.
- Multi-layer protocol solutions should be manageable through MIB - Multi-layer protocol solutions should be manageable through MIB
modules, ([MLN-REQ], Section 5.10). modules ([RFC5212], Section 5.10).
o See section 3.1.5.1. o See Section 3.1.5.1.
- Choices about how to coordinate errors and alarms, and how to - Choices about how to coordinate errors and alarms, and how to
operate OAM across administrative and layer boundaries must be left operate OAM across administrative and layer boundaries must be left
open for the operator, ([MLN-REQ], Section 5.10). open for the operator ([RFC5212], Section 5.10).
o This is an implementation matter, subject to operational o This is an implementation matter, subject to operational
policies. policies.
- It must be possible to enable end-to-end OAM on an upper-layer LSP. - It must be possible to enable end-to-end OAM on an upper-layer LSP.
This function appears to the ingress LSP as normal LSP-based OAM This function appears to the ingress LSP as normal LSP-based OAM
[GMPLS-OAM], but at layer boundaries, depending on the technique [GMPLS-OAM], but at layer boundaries, depending on the technique
used to span the lower layers, client-layer OAM operations may need used to span the lower layers, client-layer OAM operations may need
to be mapped to server-layer OAM operations ([MLN-REQ], Section to be mapped to server-layer OAM operations ([RFC5212], Section
5.10). 5.10).
o See Section 3.1.5.2. o See Section 3.1.5.2.
- Client layer control plane mechanisms must map and enable OAM in - Client-layer control plane mechanisms must map and enable OAM in
the server layer, ([MLN-REQ], Section 5.10). the server layer ([RFC5212], Section 5.10).
o See Section 3.1.5.2. o See Section 3.1.5.2.
- OAM operation enabled for an LSP in a client layer must operate for - OAM operation enabled for an LSP in a client layer must operate for
that LSP along its entire length, ([MLN-REQ], Section 5.10). that LSP along its entire length ([RFC5212], Section 5.10).
o See Section 3.1.5.2. o See Section 3.1.5.2.
- OAM function operating within a server layer must be controllable - OAM function operating within a server layer must be controllable
from the client layer. Such control should be subject to policy at from the client layer. Such control should be subject to policy at
the layer boundary, ([MLN-REQ], Section 5.10). the layer boundary ([RFC5212], Section 5.10).
o This is an implementation matter. o This is an implementation matter.
- The status of a server layer LSP must be available to the client - The status of a server layer LSP must be available to the client
layer. This information should be configurable to be automatically layer. This information should be configurable to be automatically
notified to the client layer at the layer boundary, and should be notified to the client layer at the layer boundary, and should be
subject to policy, ([MLN-REQ], Section 5.10). subject to policy ([RFC5212], Section 5.10).
o This is an implementation matter. o This is an implementation matter.
- Implementations may use standardized techniques (such as MIB - Implementations may use standardized techniques (such as MIB
modules) to convey status information between layers. modules) to convey status information between layers.
o This is an implementation matter. o This is an implementation matter.
5. Security Considerations 5. Security Considerations
[MLN-REQ] sets out the security requirements for operating a MLN or [RFC5212] sets out the security requirements for operating a MLN or
MRN. These requirements are, in general, no different from the MRN. These requirements are, in general, no different from the
security requirements for operating any GMPLS network. As such, the security requirements for operating any GMPLS network. As such, the
GMPLS protocols already provide adequate security features. An GMPLS protocols already provide adequate security features. An
evaluation of the security features for GMPLS networks may be found evaluation of the security features for GMPLS networks may be found
in [MPLS-SEC], and where issues or further work is identified by that in [MPLS-SEC], and where issues or further work is identified by that
document, new security features or procedures for the GMPLS protocols document, new security features or procedures for the GMPLS protocols
will need to be developed. will need to be developed.
[MLN-REQ] also identifies that where the separate layers of a MLN/MRN [RFC5212] also identifies that where the separate layers of a MLN/MRN
network are operated as different administrative domains, additional are operated as different administrative domains, additional security
security considerations may be given to the mechanisms for allowing considerations may be given to the mechanisms for allowing inter-
inter-layer LSP setup. However, this document is explicitly limited layer LSP setup. However, this document is explicitly limited to the
to the case where all layers under GMPLS control are part of the same case where all layers under GMPLS control are part of the same
administrative domain. administrative domain.
Lastly, as noted in [MLN-REQ], it is expected that solution documents Lastly, as noted in [RFC5212], it is expected that solution documents
will include a full analysis of the security issues that any protocol will include a full analysis of the security issues that any protocol
extensions introduce. extensions introduce.
6. IANA Considerations 6. Acknowledgments
This informational document makes no requests for IANA action.
7. Acknowledgments
We would like to thank Julien Meuric, Igor Bryskin, and Adrian Farrel We would like to thank Julien Meuric, Igor Bryskin, and Adrian Farrel
for their useful comments. for their useful comments.
Thanks also to Question 14 of Study Group 15 of the ITU-T for their Thanks also to Question 14 of Study Group 15 of the ITU-T for their
thoughtful review. thoughtful review.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003. 3471, January 2003.
[RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching Architecture", RFC 3945, October 2004 Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Extensions in Support of Generalized Multi-Protocol Label
Label Switching", RFC4202, October 2005. Switching (GMPLS)", RFC 4202, October 2005.
[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
Vigoureux, M., Brungard, D., "Requirements for GMPLS- M., and D. Brungard, "Requirements for GMPLS-Based
based multi-region and multi-layer networks", draft- Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC
ietf-ccamp-gmpls-mln-reqs, work in progess. 5212, July 2008.
8.2. Informative References 7.2. Informative References
[RFC3473] Berger, L., et al. "GMPLS Signaling RSVP-TE [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
extensions", RFC3473, January 2003. Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
Support of Generalized Multi-Protocol Label in Support of Generalized Multi-Protocol Label Switching
Switching", RFC4203, Oct. 2005. (GMPLS)", RFC 4203, October 2005.
[RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, September 2005. 4204, October 2005.
[RFC4205] K. Kompella, and Y. Rekhter, "Intermediate System to [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
Intermediate System (IS-IS) Extensions in Support of System to Intermediate System (IS-IS) Extensions in
Multi-Protocol Label Switching (GMPLS)", RFC 4205, Support of Generalized Multi-Protocol Label Switching
October 2005. (GMPLS)", RFC 4205, October 2005.
[RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
generalized MPLS TE", RFC4206, October 2005. Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005.
[RFC4220] Dubuc, M., Nadeau, T., and Lang, J., "Traffic [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering
Engineering Link Management Information Base", RFC 4220, Link Management Information Base", RFC 4220, November
November 2005. 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Architecture", RFC4655, August 2006. Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized [RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm
Multiprotocol Label Switching (GMPLS) Traffic Information", RFC 4783, December 2006.
Engineering Management Information Base", RFC 4802,
February 2007.
[RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base", RFC 4802, February 2007.
[RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Label Switching Multiprotocol Label Switching (GMPLS) Label Switching
Router (LSR) Management Information Base", RFC 4803, Router (LSR) Management Information Base", RFC 4803,
February 2007. February 2007.
[RFC4783] L. Berger, Ed., "GMPLS - Communication of Alarm [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Information", RFC 4783, December 2006. Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
[RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in Recovery", RFC 4872, May 2007.
support of End-to-End Generalized Multi-Protocol Label
Switching (GMPLS)-based Recovery", RFC4872, May 2007.
[RFC4974] Papadimitriou, D., Farrel, A., et. al., "Generalized [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS
MPLS (GMPLS) RSVP-TE Signaling Extensions in support of (GMPLS) RSVP-TE Signaling Extensions in Support of
Calls", RFC 4974, August 2007. Calls", RFC 4974, August 2007.
[ETH-OAM] Takacs, A., Gero, B., "GMPLS RSVP-TE Extensions to [ETH-OAM] Takacs, A., Gero, B., and D. Mohan, "GMPLS RSVP-TE
Control Ethernet OAM", draft-takacs-ccamp-rsvp-te-eth- Extensions to Control Ethernet OAM", Work in Progress,
oam-ext, work in progress. July 2008.
[GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and Farrel, A., [GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and A. Farrel, "OAM
"OAM Requirements for Generalized Multi-Protocol Label Switching Requirements for Generalized Multi-Protocol Label
(GMPLS) Networks", draft-ietf-ccamp-gmpls-oam-requirements, work in Switching (GMPLS) Networks", Work in Progress, October
progress. 2007.
[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic [GR-SHUT] Ali, Z., Zamfir, A., and J. Newton, "Graceful Shutdown in
Engineering Network", draft-ietf-ccamp-mpls-graceful- MPLS and Generalized MPLS Traffic Engineering Networks",
shutdown, work in progress. Work in Progress, July 2008.
[HIER-BIS] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A., and [HIER-BIS] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A., and
Ali, Z., "Procedures for Dynamically Signaled Z. Ali, "Procedures for Dynamically Signaled Hierarchical
Hierarchical Label Switched Paths", draft-ietf-ccamp- Label Switched Paths", Work in Progress, February 2008.
lsp-hierarchy-bis, work in progress.
[MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS [MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks draft-fang-mpls-gmpls-security-framework, work Networks", Work in Progress, July 2008.
in progress.
[PCE-INTER] Oki, E., Le Roux , J-L., and Farrel, A., "Framework for [PCE-INTER] Oki, E., Le Roux , J-L., and A. Farrel, "Framework for
PCE-Based Inter-Layer MPLS and GMPLS Traffic PCE-Based Inter-Layer MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-layer-frwk, work in Engineering", Work in Progress, June 2008.
progress.
[TED-MIB] Miyazawa, M., Otani, T., Kunaki, K. and Nadeau, T.,
"Traffic Engineering Database Management Information
Base in support of GMPLS", draft-ietf-ccamp-gmpls-ted-
mib, work in progress.
9. Editors' Addresses
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
Email: jeanlouis.leroux@orange-ftgroup.com
Dimitri Papadimitriou [TED-MIB] Miyazawa, M., Otani, T., Nadeau, T., and K. Kunaki,
Alcatel-Lucent "Traffic Engineering Database Management Information Base
Francis Wellensplein 1, in support of MPLS-TE/GMPLS", Work in Progress, July
B-2018 Antwerpen, Belgium 2008.
Email: dimitri.papadimitriou@alcatel-lucent.be
10. Contributors' Addresses 8. Contributors' Addresses
Deborah Brungard Deborah Brungard
AT&T AT&T
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ, 07748 USA Middletown, NJ, 07748 USA
E-mail: dbrungard@att.com EMail: dbrungard@att.com
Eiji Oki Eiji Oki
NTT NTT
3-9-11 Midori-Cho 3-9-11 Midori-Cho
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp EMail: oki.eiji@lab.ntt.co.jp
Kohei Shiomoto Kohei Shiomoto
NTT NTT
3-9-11 Midori-Cho 3-9-11 Midori-Cho
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp EMail: shiomoto.kohei@lab.ntt.co.jp
M. Vigoureux M. Vigoureux
Alcatel-Lucent France Alcatel-Lucent France
Route de Villejust Route de Villejust
91620 Nozay 91620 Nozay
FRANCE FRANCE
Email: martin.vigoureux@alcatel-lucent.fr EMail: martin.vigoureux@alcatel-lucent.fr
11. Intellectual Property Statement Editors' Addresses
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
EMail: jeanlouis.leroux@orange-ftgroup.com
Dimitri Papadimitriou
Alcatel-Lucent
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
EMail: dimitri.papadimitriou@alcatel-lucent.be
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. 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, THE
IETF TRUST 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 IETF Trust (2008). 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.
 End of changes. 182 change blocks. 
486 lines changed or deleted 496 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/