draft-ietf-ccamp-gmpls-mln-eval-01.txt   draft-ietf-ccamp-gmpls-mln-eval-02.txt 
Network Working Group J.L. Le Roux (France Telecom) Network Working Group J.L. Le Roux (France Telecom)
Internet Draft D. Brungard (AT&T) Internet Draft D. Brungard (AT&T)
Category: Informational E. Oki (NTT) Category: Informational E. Oki (NTT)
Expires: January 2007 D. Papadimitriou (Alcatel) Expires: April 2007 D. Papadimitriou (Alcatel)
K. Shiomoto (NTT) K. Shiomoto (NTT)
M. Vigoureux (Alcatel) M. Vigoureux (Alcatel)
October 2006
Evaluation of existing GMPLS Protocols against Multi Layer Evaluation of existing GMPLS Protocols against Multi Layer
and Multi Region Networks (MLN/MRN) and Multi Region Networks (MLN/MRN)
draft-ietf-ccamp-gmpls-mln-eval-01.txt draft-ietf-ccamp-gmpls-mln-eval-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 16 skipping to change at page 2, line 16
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119. document are to be interpreted as described in RFC-2119.
Table of Contents Table of Contents
1. Terminology.................................................3 1. Terminology.................................................3
2. Introduction................................................3 2. Introduction................................................3
3. MLN/MRN Requirements Overview...............................4 3. MLN/MRN Requirements Overview...............................4
4. Analysis....................................................5 4. Analysis....................................................4
4.1. Multi-Layer Aspects.........................................5 4.1. Multi-Layer Aspects.........................................4
4.1.1. Support for Virtual Network Topology Reconfiguration........5 4.1.1. Support for Virtual Network Topology Reconfiguration........4
4.1.1.1. Control of FA-LSPs Setup/Release..........................5 4.1.1.1. Control of FA-LSPs Setup/Release..........................5
4.1.1.2. Virtual TE-Links..........................................7 4.1.1.2. Virtual TE-Links..........................................6
4.1.1.3. Traffic Disruption Minimization During FA Release.........8 4.1.1.3. Traffic Disruption Minimization During FA Release.........8
4.1.1.4. Stability.................................................8 4.1.1.4. Stability.................................................8
4.1.2. Support for FA-LSP Attributes Inheritance...................8 4.1.2. Support for FA-LSP Attributes Inheritance...................8
4.1.3. Support for Triggered Signaling.............................9 4.1.3. Support for Triggered Signaling.............................8
4.1.4. FA Connectivity Verification................................9 4.1.4. FA Connectivity Verification................................9
4.2. Multi-Region Specific Aspects...............................9 4.2. Multi-Region Specific Aspects...............................9
4.2.1. Support for Multi-Region Signaling..........................9 4.2.1. Support for Multi-Region Signaling..........................9
4.2.2. Advertisement of Internal Adaptation Capabilities..........10 4.2.2. Advertisement of Internal Adaptation Capabilities..........10
4.3. Client and server network aspects..........................12
4.3.1. Administrative boundary....................................12
4.3.2. Path computation across separated TEDs.....................12
4.3.3. Association between TE-links in separated TEDs.............12
5. Evaluation Conclusion......................................12 5. Evaluation Conclusion......................................12
6. Security Considerations....................................13 6. Security Considerations....................................13
7. Acknowledgments............................................13 7. Acknowledgments............................................13
8. References.................................................13 8. References.................................................13
8.1. Normative..................................................13 8.1. Normative..................................................13
8.2. Informative................................................14 8.2. Informative................................................13
9. Authors' Addresses:........................................14 9. Authors' Addresses:........................................14
10. Intellectual Property Statement............................15 10. Intellectual Property Statement............................15
1. Terminology 1. Terminology
This document uses terminologies defined in [RFC3945], [HIER], and This document uses terminologies defined in [RFC3945], [RFC4206], and
[MLN-REQ]. [MLN-REQ].
2. Introduction 2. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to
handle multiple switching technologies: packet switching (PSC), handle multiple switching technologies: packet switching (PSC),
layer-two switching (L2SC), TDM switching (TDM), wavelength switching layer-two switching (L2SC), TDM switching (TDM), wavelength switching
(LSC) and fiber switching (FSC) (see [RFC 3945]). (LSC) and fiber switching (FSC) (see [RFC 3945]).
A data plane layer is a collection of network resources capable of A data plane layer is a collection of network resources capable of
terminating and/or switching data traffic of a particular format. For terminating and/or switching data traffic of a particular format. For
example, LSC, TDM VC-11 and TDM VC-4-64c represent three different example, LSC, TDM VC-11 and TDM VC-4-64c represent three different
layers. A network comprising transport nodes with different data layers. A network comprising transport nodes with different data
plane switching layers controlled either by a single GMPLS control plane switching layers controlled by a single GMPLS control plane
plane instance is called a Multi-Layer Network (MLN). instance is called a Multi-Layer Network (MLN).
A GMPLS switching type (PSC, TDM, etc.) describes the ability of a A GMPLS switching type (PSC, TDM, etc.) describes the ability of a
node to forward data of a particular data plane technology, and node to forward data of a particular data plane technology, and
uniquely identifies a control plane region. The notion of LSP Region uniquely identifies a control plane region. The notion of LSP Region
is defined in [HIER]. A network comprised of multiple switching types is defined in [RFC4206]. A network comprised of multiple switching
(e.g. PSC and TDM) controlled by a single GMPLS control plane types (e.g. PSC and TDM) controlled by a single GMPLS control plane
instance is called a Multi-Region Network (MRN). instance is called a Multi-Region Network (MRN).
Note that the region is a control plane only concept. That is, layers Note that the region is a control plane only concept. That is, layers
of the same region share the same switching technology and, of the same region share the same switching technology and,
therefore, need the same set of technology specific signaling therefore, need the same set of technology specific signaling
objects. objects.
Note that a MRN is necessarily a MLN, but not vice versa, as a MLN Note that a MRN is necessarily a MLN, but not vice versa, as a MLN
may consist of a single region (control of multiple data plane layers may consist of a single region (control of multiple data plane layers
within a region). Hence, in the following, we use the term layer if within a region). Hence, in the following, we use the term layer if
the mechanism discussed applies equally to layers and regions (e.g. the mechanism discussed applies equally to layers and regions (e.g.
VNT, virtual TE-link, etc.), and we specifically use the term region VNT, virtual TE-link, etc.), and we specifically use the term region
if the mechanism applies only for supporting a MRN. if the mechanism applies only for supporting a MRN.
A customer network may be provided on top of a server GMPLS-based
MRN/MLN which is operated by a service provider. For example, a pure
IP and/or an IP/MPLS network can be provided on top of GMPLS-based
packet over optical networks [IW-MIG-FW]. The relationship between
the networks is a client/server relationship and such services are
referred to as "MRN/MLN services". In this case, the customer network
may form part of the MRN/MLN, or may be partially separated, for
example to maintain separate routing information but retain common
signalling.
The objectives of this document are to evaluate existing GMPLS The objectives of this document are to evaluate existing GMPLS
mechanisms and protocols ([RFC 3945], [GMPLS-RTG], [GMPLS-SIG]) mechanisms and protocols ([RFC 3945], [RFC4202], [RFC3471]) against
against the requirements for MLN and MRN, defined in [MLN-REQ]. From the requirements for MLN and MRN, defined in [MLN-REQ]. From this
this evaluation, we identify several areas where additional protocol evaluation, we identify several areas where additional protocol
extensions and modifications are required to meet these requirements, extensions and modifications are required to meet these requirements,
and provide guidelines for potential extensions. and provide guidelines for potential extensions.
Section 3 provides an overview of MLN/MRN requirements. An overview of MLN/MRN requirements is provided in section 3. Then
Section 4 evaluates for each of these requirements, whether current section 4 evaluates for each of these requirements, whether current
GMPLS protocols and mechanisms allow addressing the requirements. GMPLS protocols and mechanisms allow addressing the requirements.
When the requirements are not met, the document identifies whether When the requirements are not met, the document identifies whether
the required mechanisms could rely on GMPLS protocols and procedure the required mechanisms could rely on GMPLS protocols and procedure
extensions or if it is entirely out of the scope of GMPLS protocols. extensions or if it is entirely out of 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. control plane partition.
3. MLN/MRN Requirements Overview 3. MLN/MRN Requirements Overview
skipping to change at page 4, line 31 skipping to change at page 4, line 21
[MLN-REQ] lists a set of functional requirements for Multi [MLN-REQ] lists a set of functional requirements for Multi
Layer/Region Networks (MLN/MRN). These requirements are summarized Layer/Region Networks (MLN/MRN). These requirements are summarized
below: below:
- Support of robust Virtual Network Topology (VNT) - Support of robust Virtual Network Topology (VNT)
reconfiguration. This implies the following requirements: reconfiguration. This implies the following requirements:
- Optimal control of FA-LSP setup and release; - Optimal control of FA-LSP setup and release;
- Support for virtual TE-links; - Support for virtual TE-links;
- Traffic Disruption minimization during FA-LSP release - Traffic Disruption minimization during FA-LSP release
(e.g. network reconfiguration events); (e.g. network reconfiguration events);
- Stability - Stability;
- Support for FA-LSP attributes inheritance; - Support for FA-LSP attributes inheritance;
- Support for Triggered Signaling; - Support for Triggered Signaling;
- Support for FA data plane connectivity verification; - Support for FA-LSP data plane connectivity verification;
- Support for Multi-region signaling; - Support for Multi-Region signaling;
- Advertisement of the adaptation capabilities and resources; - Advertisement of the adaptation capabilities and resources;
Interconnection of MLN/MRN (server) networks with administratively
separated client networks introduces as set of specific requirements:
- Support for administrative boundary between client and server
MLN/MRN network , minimizing impact on the customer network
design, operation, and administration;
- Support for path computation across separated TEDs associated
with client and server MLN/MRN network;
- Support for association between TE-links in separated TEDs
associated with client and server MLN/MRN networks;
4. Analysis 4. Analysis
4.1. Multi-Layer Aspects 4.1. Multi-Layer Aspects
4.1.1. Support for Virtual Network Topology Reconfiguration 4.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. By reconfiguring the VNT (FA-LSP (VNT) to the upper-layer. 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 of a layer, network performance factors such destination node pairs of a layer, network performance factors such
skipping to change at page 5, line 32 skipping to change at page 5, line 15
4.1.1.1. Control of FA-LSPs Setup/Release 4.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, 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 a new VNT. compute a new VNT.
Several building blocks are required to support such TE mechanism: Several functional building blocks are required to support such TE
mechanism:
- Discovery of TE topology and available resources; - Discovery of TE topology and available resources.
- Collection of traffic demands of the upper layer; - Collection of traffic demands of the upper layer.
- VNT resources policing/scheduling with regards to traffic - VNT resources policing/scheduling with regards to traffic
demands and usage (i.e. decision to setup/release FAs); The demands and usage (i.e. decision to setup/release FAs); The
functional component in charge of this function is called a functional component in charge of this function is called a
VNT Manager (VNTM), it may be distributed on network VNT Manager (VNTM), it may be distributed on network
elements or centralized on an external tool (see [VNTM]). It elements or centralized on an external tool (see [VNTM]). It
may also be partially centralized and distributed; may also be partially centralized and distributed.
- VNT Path Computation according to TE topology, and - VNT Path Computation according to TE topology, and potentially
potentially taking into account old VNT (to minimize taking into account old VNT (to minimize changes); The
changes); The Functional component in charge of VNT Functional component in charge of VNT computation may be
computation may be distributed on network elements or may be distributed on network elements or may be centralized on an
centralized on an external tool (such as e.g. a PCE); external tool (such as e.g. a PCE).
- FA-LSP setup/release. - FA-LSP setup/release.
GMPLS routing protocols support TE topology discovery and GMPLS routing protocols support TE topology discovery. GMPLS
GMPLS signaling protocols allow setting up/releasing FA-LSPs. signaling protocols allow setting up/releasing FA-LSPs.
VNT Management functions (resources policing/scheduling, decision to VNT Management functions (resources policing/scheduling, decision to
setup/release FA, FA configuration) are out of the scope of GMPLS setup/release FA, FA configuration) are out of the scope of GMPLS
protocols. Such functionalities can be achieved directly on layer protocols. Such functionalities can be achieved directly on layer
border LSRs, and/or on one or more external tools. When an external border LSRs, and/or on one or more external tools. When an external
tool is used, an interface is required between the VNTM and network tool is used, an interface is required between the VNTM and network
elements so has to setup/releases FA-LSPs. This may rely on SNMP (TE elements so has to setup/releases FA-LSPs. This may rely on SNMP (TE
MIB) or proprietary interfaces. MIB) or on proprietary interfaces.
The set of traffic demands of the upper layer is required for the VNT The set of traffic demands of the upper layer is required for the VNT
Manager to take decisions to setup/release FAs. This requires Manager to take decisions to setup/release FAs. This requires
knowledge of the aggregated bandwidth reserved by upper layer LSPs knowledge of the aggregated bandwidth reserved by upper layer LSPs
established between any pair of border LSRs. established between any pair of border LSRs.
Existing GMPLS routing allows for the collection of traffic demands Existing GMPLS routing allows for the collection of traffic demands
of the upper region. It can be deduced from FA TE-link advertisements. of the upper region. It can be deduced from FA TE-link advertisements.
The set of traffic demands can be inferred: The set of traffic demands can be inferred:
- either directly, based on upper-layer FA TE-link advertisements. - either directly, based on upper-layer FA TE-link advertisements.
The traffic demands between two points correspond to the The traffic demands between two points correspond to the
cumulated bandwidth reserved by upper-layer LSPs between these cumulated bandwidth reserved by upper-layer LSPs between these
two points; two points;
- or indirectly, based on lower-layer FA TE-link advertisements. - or indirectly, based on lower-layer FA TE-link advertisements.
In this case a mechanism to infer the upper-layer traffic demand In this case a mechanism to infer the upper-layer traffic demand
from the aggregated bandwidth reserved in lower-layer LSPs might from the aggregated bandwidth reserved in lower-layer LSPs might
be required, as all pairs of border nodes may not be directly be required, as all pairs of border nodes may not be directly
connected by a lower layer LSP. connected by a lower layer LSP.
Collection of traffic demands of an upper region may actually be Collection of traffic demands of an upper region may actually be
skipping to change at page 6, line 32 skipping to change at page 6, line 16
cumulated bandwidth reserved by upper-layer LSPs between these cumulated bandwidth reserved by upper-layer LSPs between these
two points; two points;
- or indirectly, based on lower-layer FA TE-link advertisements. - or indirectly, based on lower-layer FA TE-link advertisements.
In this case a mechanism to infer the upper-layer traffic demand In this case a mechanism to infer the upper-layer traffic demand
from the aggregated bandwidth reserved in lower-layer LSPs might from the aggregated bandwidth reserved in lower-layer LSPs might
be required, as all pairs of border nodes may not be directly be required, as all pairs of border nodes may not be directly
connected by a lower layer LSP. connected by a lower layer LSP.
Collection of traffic demands of an upper region may actually be Collection of traffic demands of an upper region may actually be
achieved in several ways depending on the location of VNT Managers: achieved in several ways depending on the location of VNT Managers:
- If a VNTM is distributed on border layer LSRs, then - If a VNTM is distributed on border layer LSRs, then the
the collection of traffic demands would rely on existing GMPLS collection of traffic demands would rely on existing GMPLS
routing, as per described above; routing, as per described above;
- If a VNTM is centralized on an external tool, then the - If a VNTM is centralized on an external tool, then the
collection of traffic demands may be achieved using collection of traffic demands may be achieved using existing
existing GMPLS routing, provided that the tool relies on GMPLS GMPLS routing, provided that the tool relies on GMPLS routing to
routing to discover TE link information, or it may rely on discover TE link information, or it may rely on another
another mechanism out of the scope of GMPLS protocols (e.g. mechanism out of the scope of GMPLS protocols (e.g. SNMP TE-link
SNMP TE-link MIB). MIB).
Finally, VNT computation can be performed directly on layer border Finally, VNT computation can be performed directly on layer border
LSRs or on an external tool (such as an external PCE) and this LSRs or on an external tool (such as an external PCE) and this
independently of the location of the VNTM. VNT computation is independently of the location of the VNTM. VNT computation is
triggered by the VNTM (e.g. when the Path computation is externalized triggered by the VNTM (e.g. when the Path computation is externalized
on a PCE, the VNTM acts as PCC). on a PCE, the VNTM acts as PCC).
Hence no GMPLS protocol extensions are required to control FA-LSP Hence no GMPLS protocol extensions are required to control FA-LSP
setup/release. setup/release.
4.1.1.2. Virtual TE-Links 4.1.1.2. Virtual TE-Links
A Virtual TE-link is a TE-link between two nodes, not actually A Virtual TE-link is a TE-link between two nodes, not actually
associated to a fully provisioned FA-LSP. A Virtual TE-link associated to a fully provisioned FA-LSP. A Virtual TE-link
represents the potentiality to setup a FA-LSP. There is no IGP represents the potentiality to setup a FA-LSP. There is no IGP
adjacency associated to a Virtual TE-link. A Virtual TE-link is adjacency associated to a Virtual TE-link. A Virtual TE-link is
advertised as any classical TE-link, i.e. following the rules in advertised as any classical TE-link, i.e. following the rules in
[HIER] defined for fully provisioned TE-links. Particularly, the [RFC4206] defined for fully provisioned TE-links. Particularly, the
flooding scope of a Virtual TE-link is within an IGP area, as any TE- flooding scope of a Virtual TE-link is within an IGP area, as any TE-
link. link.
During its signalling, if an upper-layer LSP makes use of a Virtual During its signalling, if an upper-layer LSP makes use of a Virtual
TE-link, the underlying FA-LSP is immediately signalled and TE-link, the underlying FA-LSP is immediately signalled and
provisioned. provisioned.
The use of Virtual TE-links has two main advantages: The use of Virtual TE-links has two main advantages:
- flexibility: allows to compute a LSP path using TE-links and this - flexibility: allows to compute a LSP path using TE-links and this
without taking into account the actual status of the without taking into account the actual status of the
corresponding FA-LSP in the lower layer in terms of provisioning; corresponding FA-LSP in the lower layer in terms of provisioning;
- stability: allows stability of TE-links in the upper layer, while
- stability: allows stability of TE-links, while avoiding wastage avoiding wastage of bandwidth in the lower layer, as data plane
of bandwidth in the lower layer, as data connections are not established.
plane connections are not established.
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 signalling mechanism for the dynamic setup and deletion of - A signalling mechanism for the dynamic setup and deletion of
virtual TE-links. Setting up a virtual TE-link requires a virtual TE-links. Setting up a virtual TE-link requires a
signalling mechanism allowing an end-to-end association signalling mechanism allowing an end-to-end association
between Virtual TE-link end points so as to exchange link between Virtual TE-link end points so as to exchange link
identifiers as well as some TE parameters. identifiers as 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 signalling does not allow setting up and releasing
Virtual TE-links. Hence GMPLS signaling must be extended to support Virtual TE-links. Hence GMPLS signalling 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 - The Soft FA approach, that consists of setting up the FA-LSP
in the control plane without actually activating cross connections in in the control plane without actually activating cross connections in
the data plane. One the one hand, this requires state maintenance on the data plane. One the one hand, this requires state maintenance on
all transit LSRs (N square issue), but on the other hand this may all transit LSRs (N square issue), but on the other hand this may
allow for some admission control. Indeed, when a soft-FA is allow for some admission control. Indeed, when a soft-FA is
activated, there may be no longer available resources for other soft- activated, there may be no longer available resources for other soft-
FAs that were sharing common links, these soft-FA will be dynamically FAs that were sharing common links, these soft-FA will be dynamically
released and corresponding virtual TE-links are deleted. The soft-FA released and corresponding virtual TE-links are deleted. The soft-FA
LSPs may be setup using procedures similar to those described in LSPs may be setup using procedures similar to those described in
[GMPLS-RECOVERY] for setting up secondary LSPs. [GMPLS-RECOVERY] for setting up secondary LSPs.
-The remote association approach, that simply consists of -The remote association approach, that simply consists of
exchanging virtual TE-links ids and parameters directly between TE- exchanging virtual TE-links ids and parameters directly between TE-
link end points. This does not require state maintenance on transit link end points. This does not require state maintenance on transit
LSRs, but reduce admission control capabilities. Such an association LSRs, but reduce 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 ([GMPLS-ASON]). RSVP-TE ASON Call procedure ([ASON-CALL]).
Note that the support of Virtual TE-link does not require any GMPLS Note that the support of Virtual TE-link does not require any GMPLS
routing extension. routing extension.
4.1.1.3. Traffic Disruption Minimization During FA Release 4.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 mechanisms required here are similar to those required for The mechanisms required here are similar to those required for
graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism
skipping to change at page 9, line 21 skipping to change at page 9, line 4
When a LSP crosses the boundary from an upper to a lower layer, it When a LSP crosses the boundary from an upper to a lower layer, it
may be nested in or stitched to a lower-layer LSP. If such an LSP may be nested in or stitched to a lower-layer LSP. If such an LSP
does not exist the LSP may be established dynamically. Such a does not exist the LSP may be established dynamically. Such a
mechanism is referred to as "Triggered signaling". mechanism is referred to as "Triggered signaling".
Triggered signaling requires the following building blocks: Triggered signaling requires the following building blocks:
- The identification of layer boundaries. - The identification of layer boundaries.
- A path computation engine capable of computing a path - A path computation engine capable of computing a path
containing multiple layers. containing multiple layers.
- A mechanism for nested signaling. - A mechanism for nested signaling.
The identification of layer boundaries is supported by GMPLS routing The identification of layer boundaries is supported by GMPLS routing
protocols. The identification of layer boundaries is performed using protocols. The identification of layer boundaries is performed using
the interface switching capability descriptor associated to the TE- the interface switching capability descriptor associated to the TE-
link (see [HIER] and [GMPLS-RTG]). link (see [RFC4206] and [RFC4202]).
The capability to compute a path containing multiple layers is a The capability to compute a path containing multiple layers is a
local implementation issue and is out of the scope of GMPLS protocols. local implementation issue and is out of the scope of GMPLS protocols.
A mechanism for nested signaling is defined in [HIER]. A mechanism for nested signaling is defined in [RFC4206].
Hence, GMPLS protocols already meet this requirement. Hence, GMPLS protocols already meet this requirement.
4.1.4. FA Connectivity Verification 4.1.4. FA Connectivity Verification
Once fully provisioned, FA liveliness may be achieved by verifying Once fully provisioned, FA liveliness may be achieved by verifying
its data plane connectivity. its data plane connectivity.
FA connectivity verification relies on technology specific mechanisms FA connectivity verification relies on technology specific mechanisms
(e.g. for SDH, G.707, G.783, for MPLS, BFD, etc.) as for any other (e.g. for SDH, G.707, G.783, for MPLS, BFD, etc.) as for any other
skipping to change at page 10, line 22 skipping to change at page 10, line 11
expansion, or when an ERO sub-object identifies a multi-SC TE-link. expansion, or when an ERO sub-object identifies a multi-SC TE-link.
This would give the possibility to optimize resource usage on a This would give the possibility to optimize resource usage on a
multi-region basis. multi-region basis.
4.2.2. Advertisement of Internal Adaptation Capabilities 4.2.2. Advertisement of Internal Adaptation Capabilities
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. Hybrid capability on at least one interface are called Hybrid nodes. Hybrid
nodes contain at least two distinct switching elements that are nodes contain at least two distinct switching elements that are
interconnected by internal links to provide adaptation between the interconnected by internal links to provide adaptation between the
supported switching capabilities. supported switching capabilities. These internal links have finite
These internal links have finite capacities and must be taken into capacities and must be taken into account when computing the path of
account when computing the path of a multi-region TE-LSP. a multi-region TE-LSP. The advertisement of the internal adaptation
The advertisement of the internal adaptation capability is required capability is required as it provides critical information when
as it provides critical information when performing multi-region path performing multi-region path computation.
computation.
Figure 1a below shows an example of hybrid node. The hybrid node has Figure 1a below shows an example of hybrid node. The hybrid node has
two switching elements (matrices), which support here TDM and PSC two switching elements (matrices), which support here TDM and PSC
switching respectively. The node terminates two PSC and TDM ports switching respectively. The node terminates two PSC and TDM ports
(port1 and port2 respectively). It also has internal link connecting (port1 and port2 respectively). It also has internal link connecting
the two 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 adaptation for PSC traffic, port 2 and provide through them adaptation for PSC traffic,
received/sent over the internal PSC interface (#b). Two ways are received/sent over the internal PSC interface (#b). Two ways are
skipping to change at page 11, line 40 skipping to change at page 11, line 40
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, there is only 155 Mb capacities 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 on
port #d. 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 155Mb still
available for TDM-PSC adaptation. Hence the internal TDM-PSC available for TDM-PSC adaptation. Hence the internal TDM-PSC
adaptation capability must be advertised. adaptation capability must be advertised.
With current GMPLS routing [GMPLS-RTG] 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 (port 1):
- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb, unreserved - ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb, unreserved
bandwidth = 622Mb. bandwidth = 622Mb.
TE-Link 2 (port 2): TE-Link 2 (port 2):
- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
unreserved bandwidth = vc4-5c. unreserved bandwidth = vc4-5c.
- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb, - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,
unreserved bandwidth = 155 Mb. unreserved bandwidth = 155 Mb.
skipping to change at page 12, line 19 skipping to change at page 12, line 19
the adaptation capability information is lost with current GMPLS the adaptation capability 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 (port 1 + port 2):
- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
unreserved bandwidth = vc4-5c. unreserved bandwidth = vc4-5c.
- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb, - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,
unreserved bandwidth = 777 Mb. unreserved bandwidth = 777 Mb.
With such TE-link advertisement an element computing the path of a With such 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
internal adaptation capability but this precludes performing link internal adaptation capability but this precludes performing link
bundling and thus faces significant scalability limitations. bundling 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 internal adaptation could rely on the advertisement of the internal adaptation capability
capabilitiy as a new TE link attribute (that would complement the as a new TE link attribute (that would complement the Interface
Interface Switching Capability Descriptor TE-link attribute). Switching Capability Descriptor TE-link attribute).
4.3. Client and server network aspects
4.3.1. Administrative boundary
TBD
4.3.2. Path computation across separated TEDs
TBD
4.3.3. Association between TE-links in separated TEDs
TBD
5. Evaluation Conclusion 5. Evaluation Conclusion
Most of MLN/MRN requirements will rely on mechanisms and procedures Most of the required MLN/MRN functions will rely on mechanisms and
that are out of the scope of the GMPLS protocols, and thus do not procedures that are out of the scope of the GMPLS protocols, and thus
require any GMPLS protocol extensions. They will rely on local do not require any GMPLS protocol extensions. They will rely on local
procedures and policies, and on specific TE mechanisms and 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 that could for instance rely reconfiguration, specific TE mechanisms that could for instance rely
on PCE based mechanisms and protocols, need to be defined, but these on PCE based mechanisms and protocols, need to be defined, but these
mechanisms are out of the scope of GMPLS protocols. mechanisms are out of the scope of GMPLS protocols.
Four areas for extensions of GMPLS protocols and procedures have been Four areas for extensions of GMPLS protocols and procedures have been
identified: identified:
skipping to change at page 13, line 48 skipping to change at page 13, line 31
8. References 8. References
8.1. Normative 8.1. Normative
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005. Technology", BCP 79, RFC 3979, March 2005.
[RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label [RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label
Switching Architecture", RFC 3945, October 2004 Switching Architecture", RFC 3945, October 2004
[GMPLS-RTG] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label Switching", Extensions in Support of Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-gmpls-routing, RFC4202, October 2005. draft-ietf-ccamp-gmpls-routing, RFC4202, October 2005.
[GMPLS-SIG] Berger, L., et. al. "Generalized Multi-Protocol Label [RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471, Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
8.2. Informative 8.2. Informative
[GMPLS-ASON] Papadimitriou, D., et. al., " Generalized MPLS (GMPLS) [ASON-CALL] Papadimitriou, D., Farrel, A., et. al., "Generalized MPLS
RSVP-TE Signaling in support of Automatically Switched Optical (GMPLS) RSVP-TE Signaling Extensions in support of Calls", draft-
Network (ASON)", draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progess. ietf-ccamp-gmpls-rsvp-te-call, work in progress.
[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,
M., Brungard, D., "Requirements for GMPLS-based multi-region and M., Brungard, D., "Requirements for GMPLS-based multi-region and
multi-layer networks", draft-ietf-ccamp-gmpls-mrn-reqs, work in multi-layer networks", draft-ietf-ccamp-gmpls-mrn-reqs, work in
progess. progess.
[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized [RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy, FRC4206, October 2005. MPLS TE", draft-ietf-mpls-lsp-hierarchy, RFC4206, October 2005.
[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic
Engineering Network", draft-ali-ccamp-mpls-graceful-shutdown, work in Engineering Network", draft-ietf-ccamp-mpls-graceful-shutdown, work
progress. in progress.
[GMPLS-RECOVERY] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in [GMPLS-RECOVERY] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
support of End-to-End Generalized Multi-Protocol Label Switching support of End-to-End Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e- (GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-
signaling, work in progress. signaling, work in progress.
[VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network [VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network
Topology Manager (VNTM) for PCE-based Inter-Layer MPLS and GMPLS Topology Manager (VNTM) for PCE-based Inter-Layer MPLS and GMPLS
Traffic Engineering", draft-oki-pce-vntm-def, work in progress. Traffic Engineering", draft-oki-pce-vntm-def, work in progress.
[IW-MIG-FMWK] Shiomoto, K et al., "Framework for IP/MPLS-GMPLS [IW-MIG-FMWK] Shiomoto, K et al., "Framework for IP/MPLS-GMPLS
interworking in support of IP/MPLS to GMPLS migration", draft-ietf- interworking in support of IP/MPLS to GMPLS migration", draft-ietf-
ccamp-mpls-gmpls-interwork-fmwk, work in progress. ccamp-mpls-gmpls-interwork-fmwk, work in progress.
9. Authors' Addresses: 9. Authors' Addresses:
Jean-Louis Le Roux (Editor) Jean-Louis Le Roux (Editor)
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex, France 22307 Lannion Cedex, France
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@orange-ft.com
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 E-mail: dbrungard@att.com
Eiji Oki Eiji Oki
NTT NTT
3-9-11 Midori-Cho 3-9-11 Midori-Cho
 End of changes. 47 change blocks. 
115 lines changed or deleted 79 lines changed or added

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