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/ |