draft-ietf-ccamp-gmpls-mln-eval-00.txt   draft-ietf-ccamp-gmpls-mln-eval-01.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: July 2006 D. Papadimitriou (Alcatel) Expires: January 2007 D. Papadimitriou (Alcatel)
K. Shiomoto (NTT) K. Shiomoto (NTT)
M. Vigoureux (Alcatel) M. Vigoureux (Alcatel)
January 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-00.txt draft-ietf-ccamp-gmpls-mln-eval-01.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....................................................4 4. Analysis....................................................5
4.1. Multi-Layer Aspects.........................................4 4.1. Multi-Layer Aspects.........................................5
4.1.1. Support for Virtual Network Topology Reconfiguration........4 4.1.1. Support for Virtual Network Topology Reconfiguration........5
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..........................................6 4.1.1.2. Virtual TE-Links..........................................7
4.1.1.3. Traffic Disruption Minimization During FA Release.........7 4.1.1.3. Traffic Disruption Minimization During FA Release.........8
4.1.1.4. Stability.................................................7 4.1.1.4. Stability.................................................8
4.1.2. Support for FA-LSP Attributes Inheritance...................7 4.1.2. Support for FA-LSP Attributes Inheritance...................8
4.1.3. Support for Triggered Signaling.............................8 4.1.3. Support for Triggered Signaling.............................9
4.1.4. FA Connectivity Verification................................8 4.1.4. FA Connectivity Verification................................9
4.2. Multi-Region Specific Aspects...............................8 4.2. Multi-Region Specific Aspects...............................9
4.2.1. Support for Multi-Region Signaling..........................8 4.2.1. Support for Multi-Region Signaling..........................9
4.2.2. Advertisement of Internal Adaptation Capabilities...........9 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....................................12 6. Security Considerations....................................13
7. Acknowledgments............................................12 7. Acknowledgments............................................13
8. References.................................................13 8. References.................................................13
8.1. Normative..................................................13 8.1. Normative..................................................13
8.2. Informative................................................13 8.2. Informative................................................14
9. Authors' Addresses:........................................13 9. Authors' Addresses:........................................14
10. Intellectual Property Statement............................14 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], [HIER], and
[MRN-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 by a single GMPLS control plane plane switching layers controlled either by a single GMPLS control
instance is called a Multi-Layer Network (MLN). plane 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 [HIER]. A network comprised of multiple switching types
(e.g. PSC and TDM) controlled by a single GMPLS control plane (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], [GMPLS-RTG], [GMPLS-SIG])
against the requirements for MLN and MRN, defined in [MRN-REQ]. From against the requirements for MLN and MRN, defined in [MLN-REQ]. From
this evaluation, we identify several areas where additional protocol this 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. Section 3 provides an overview of MLN/MRN requirements.
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
[MRN-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 - Optimal control of FA-LSP setup and release;
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 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
skipping to change at page 5, line 16 skipping to change at page 5, line 33
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 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 engine, ensuring VNT computation and reconfiguration
according to upper layer traffic demands and TE topology - VNT resources policing/scheduling with regards to traffic
(and potentially old VNT); demands and usage (i.e. decision to setup/release FAs); The
- FA-LSP setup/release; functional component in charge of this function is called a
VNT Manager (VNTM), it may be distributed on network
elements or centralized on an external tool (see [VNTM]). It
may also be partially centralized and distributed;
- VNT Path Computation according to TE topology, and
potentially taking into account old VNT (to minimize
changes); The Functional component in charge of VNT
computation may be distributed on network elements or may be
centralized on an external tool (such as e.g. a PCE);
- FA-LSP setup/release.
GMPLS routing protocols support TE topology discovery and GMPLS routing protocols support TE topology discovery and
GMPLS signaling protocols allow setting up/releasing FA-LSPs. GMPLS signaling protocols allow setting up/releasing FA-LSPs.
VNT computation and reconfiguration is out of the scope of GMPLS VNT Management functions (resources policing/scheduling, decision to
protocols. Such functionality can be achieved directly on layer setup/release FA, FA configuration) are out of the scope of GMPLS
border LSRs, or one or more external tools, as for instance Path protocols. Such functionalities can be achieved directly on layer
Computation Elements (PCE) (see [PCE-ARCH]). 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
elements so has to setup/releases FA-LSPs. This may rely on SNMP (TE
MIB) or proprietary interfaces.
The set of traffic demands of the upper layer is required to The set of traffic demands of the upper layer is required for the VNT
recompute and re-optimize the VNT. This requires knowledge of the Manager to take decisions to setup/release FAs. This requires
aggregated bandwidth reserved by upper layer LSPs established between knowledge of the aggregated bandwidth reserved by upper layer LSPs
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 of the upper region. It can be deduced from FA TE-link advertisements.
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 - either directly, based on upper-layer FA TE-link advertisements.
advertisements. The traffic demands between two points The traffic demands between two points correspond to the
correspond to the cumulated bandwidth reserved by upper-layer cumulated bandwidth reserved by upper-layer LSPs between these
LSPs between these two points; two points;
- or indirectly, based on lower-layer FA TE-link - or indirectly, based on lower-layer FA TE-link advertisements.
advertisements. In this case a mechanism to infer the upper- In this case a mechanism to infer the upper-layer traffic demand
layer traffic demand from the aggregated bandwidth reserved from the aggregated bandwidth reserved in lower-layer LSPs might
in lower-layer LSPs might be required, as all pairs of border be required, as all pairs of border nodes may not be directly
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 engines: achieved in several ways depending on the location of VNT Managers:
- If a VNT engine is distributed on border region LSRs, then the - If a VNTM is distributed on border layer LSRs, then
collection of traffic demands would rely on existing GMPLS the collection of traffic demands would rely on existing GMPLS
routing, as per described above; routing, as per described above;
- If a VNT engine is located on an external tool (e.g. a PCE) - If a VNTM is centralized on an external tool, then the
then the collection of traffic demands may be achieved using collection of traffic demands may be achieved using
existing GMPLS routing, provided that the tool relies on GMPLS existing GMPLS routing, provided that the tool relies on GMPLS
routing to discover TE link information, or it may rely on routing to discover TE link information, or it may rely on
another mechanism out of the scope of GMPLS protocols (e.g. another mechanism out of the scope of GMPLS protocols (e.g.
SNMP, PCC-PCE communication protocolů). SNMP TE-link MIB).
Finally, VNT computation can be performed directly on layer border
LSRs or on an external tool (such as an external PCE) and this
independently of the location of the VNTM. VNT computation is
triggered by the VNTM (e.g. when the Path computation is externalized
on a PCE, the VNTM acts as PCC).
Hence no GMPLS protocol extensions are required to control FA-LSP
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 [HIER] 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 signaling, 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 signaled 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, while - stability: allows stability of TE-links, while avoiding wastage
avoiding wastage of bandwidth in the lower layer, as data of bandwidth in the lower layer, as data
plane connections are not established. plane connections are not established.
Note also that it avoids state maintenance but is susceptible to
create contention if no adequate/consistent admission control is put
in place.
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 - A signalling mechanism for the dynamic setup and deletion of
virtual TE-links. Setting up a virtual TE-link virtual TE-links. Setting up a virtual TE-link requires a
requires a signaling mechanism allowing an end-to-end signalling mechanism allowing an end-to-end association
association between Virtual TE-link end points so as to between Virtual TE-link end points so as to exchange link
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 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. The association between Virtual TE-link end-points Virtual TE-links.
may rely on extensions to the RSVP-TE ASON Call procedure ([GMPLS-
ASON]). 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 control plane without actually activating cross connections in
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
allow for some admission control. Indeed, when a soft-FA is
activated, there may be no longer available resources for other soft-
FAs that were sharing common links, these soft-FA will be dynamically
released and corresponding virtual TE-links are deleted. The soft-FA
LSPs may be setup using procedures similar to those described in
[GMPLS-RECOVERY] for setting up secondary LSPs.
-The remote association approach, that simply consists of
exchanging virtual TE-links ids and parameters directly between TE-
link end points. This does not require state maintenance on transit
LSRs, but reduce admission control capabilities. Such an association
between Virtual TE-link end-points may rely on extensions to the
RSVP-TE ASON Call procedure ([GMPLS-ASON]).
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 10, line 46 skipping to change at page 11, line 46
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 [GMPLS-RTG] 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
bandwidth = 622Mb.
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.
TE-Link 2 (port 2): The ISCD 2 in TE-link 2 represents actually the internal TDM-PSC
- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb, unreserved
bandwidth = 622Mb.
The ISCD 2 in TE-link 1 represents actually the internal TDM-PSC
adaptation capability. adaptation capability.
However if for obvious scalability reasons link bundling is done then However if for obvious scalability reasons link bundling is done then
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,
skipping to change at page 11, line 28 skipping to change at page 12, line 28
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
capabilities as a new TE link attribute (that would complement the capabilitiy as a new TE link attribute (that would complement the
Interface Switching Capability Descriptor TE-link attribute). Interface 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 MLN/MRN requirements will rely on mechanisms and procedures
that are out of the scope of the GMPLS protocols, and thus do not that are out of the scope of the GMPLS protocols, and thus do not
require any GMPLS protocol extensions. They will rely on local 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:
- GMPLS signaling extension for the setup/deletion of - GMPLS signalling extension for the setup/deletion of
the virtual TE-links (as well as exact trigger for its actual the virtual TE-links (as well as exact trigger for its actual
provisioning); provisioning);
- GMPLS routing and signaling extension for graceful TE-link - GMPLS routing and signalling extension for graceful TE-link
deletion; deletion;
- GMPLS signaling extension for constrained multi-region - GMPLS signalling extension for constrained multi-region
signaling (SC inclusion/exclusion); signalling (SC inclusion/exclusion);
- GMPLS routing extension for the advertisement of the - GMPLS routing extension for the advertisement of the
internal adaptation capability of hybrid nodes. internal adaptation capability of hybrid nodes.
6. Security Considerations 6. Security Considerations
This document specifically addresses GMPLS control plane 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 and hence does not introduce additional control plane partition and hence does not introduce additional
security threats beyond those described in [RFC3945]. security threats beyond those described in [RFC3945].
skipping to change at page 13, line 17 skipping to change at page 13, line 50
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 [GMPLS-RTG] 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, work in Progress. draft-ietf-ccamp-gmpls-routing, RFC4202, October 2005.
[GMPLS-SIG] Berger, L., et. al. "Generalized Multi-Protocol Label [GMPLS-SIG] 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) [GMPLS-ASON] Papadimitriou, D., et. al., " Generalized MPLS (GMPLS)
RSVP-TE Signaling in support of Automatically Switched Optical RSVP-TE Signaling in support of Automatically Switched Optical
Network (ASON)", draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progess. Network (ASON)", draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progess.
[MRN-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-shiomoto-ccamp-gmpls-mrn-reqs, work in multi-layer networks", draft-ietf-ccamp-gmpls-mrn-reqs, work in
progess. progess.
[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture, work in
progress.
[GTEP] Oki, E., et. al., "Generalized Traffic Engineering Protocol",
draft-oki-pce-gtep, work in progress.
[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized [HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in progress. MPLS TE", draft-ietf-mpls-lsp-hierarchy, FRC4206, 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-ali-ccamp-mpls-graceful-shutdown, work in
progress. progress.
[GMPLS-RECOVERY] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
support of End-to-End Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-
signaling, work in progress.
[VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network
Topology Manager (VNTM) for PCE-based Inter-Layer MPLS and GMPLS
Traffic Engineering", draft-oki-pce-vntm-def, work in progress.
[IW-MIG-FMWK] Shiomoto, K et al., "Framework for IP/MPLS-GMPLS
interworking in support of IP/MPLS to GMPLS migration", draft-ietf-
ccamp-mpls-gmpls-interwork-fmwk, work in progress.
9. Authors' Addresses: 9. Authors' Addresses:
Jean-Louis Le Roux 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@francetelecom.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
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
 End of changes. 44 change blocks. 
97 lines changed or deleted 179 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/