draft-ietf-ccamp-gmpls-mln-eval-02.txt | draft-ietf-ccamp-gmpls-mln-eval-03.txt | |||
---|---|---|---|---|
Network Working Group J.L. Le Roux (France Telecom) | Network Working Group J.L. Le Roux (Ed.) | |||
Internet Draft D. Brungard (AT&T) | Internet Draft France Telecom | |||
Category: Informational E. Oki (NTT) | Category: Informational | |||
Expires: April 2007 D. Papadimitriou (Alcatel) | Expires: January 2008 D. Papadimitriou (Ed.) | |||
K. Shiomoto (NTT) | Alcatel-Lucent | |||
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-02.txt | draft-ietf-ccamp-gmpls-mln-eval-03.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 13 | skipping to change at page 2, line 13 | |||
requirements, and provides guidelines for potential extensions. | requirements, and provides guidelines for potential extensions. | |||
Conventions used in this document | Conventions used in this document | |||
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. Introduction................................................3 | |||
2. Introduction................................................3 | 2. MLN/MRN Requirements Overview...............................4 | |||
3. MLN/MRN Requirements Overview...............................4 | 3. Analysis....................................................4 | |||
4. Analysis....................................................4 | 3.1. Multi Layer Network Aspects.................................4 | |||
4.1. Multi-Layer Aspects.........................................4 | 3.1.1. Support for Virtual Network Topology Reconfiguration........4 | |||
4.1.1. Support for Virtual Network Topology Reconfiguration........4 | 3.1.1.1. Control of FA-LSPs Setup/Release..........................5 | |||
4.1.1.1. Control of FA-LSPs Setup/Release..........................5 | 3.1.1.2. Virtual TE-Links..........................................6 | |||
4.1.1.2. Virtual TE-Links..........................................6 | 3.1.1.3. Traffic Disruption Minimization During FA Release.........7 | |||
4.1.1.3. Traffic Disruption Minimization During FA Release.........8 | 3.1.1.4. Stability.................................................8 | |||
4.1.1.4. Stability.................................................8 | 3.1.2. Support for FA-LSP Attributes Inheritance...................8 | |||
4.1.2. Support for FA-LSP Attributes Inheritance...................8 | 3.1.3. FA-LSP Connectivity Verification............................8 | |||
4.1.3. Support for Triggered Signaling.............................8 | 3.2. Specific Aspects for Multi-Region Networks..................9 | |||
4.1.4. FA Connectivity Verification................................9 | 3.2.1. Support for Multi-Region Signaling..........................9 | |||
4.2. Multi-Region Specific Aspects...............................9 | 3.2.2. Advertisement of Internal Adaptation Capabilities...........9 | |||
4.2.1. Support for Multi-Region Signaling..........................9 | 4. Evaluation Conclusion......................................12 | |||
4.2.2. Advertisement of Internal Adaptation Capabilities..........10 | 5. Security Considerations....................................12 | |||
5. Evaluation Conclusion......................................12 | 6. Acknowledgments............................................12 | |||
6. Security Considerations....................................13 | 7. References.................................................13 | |||
7. Acknowledgments............................................13 | 7.1. Normative..................................................13 | |||
8. References.................................................13 | 7.2. Informative................................................13 | |||
8.1. Normative..................................................13 | 8. Editors' Addresses:........................................14 | |||
8.2. Informative................................................13 | 9. Contributors' Addresses:...................................14 | |||
9. Authors' Addresses:........................................14 | ||||
10. Intellectual Property Statement............................15 | 10. Intellectual Property Statement............................15 | |||
1. Terminology | 1. Introduction | |||
This document uses terminologies defined in [RFC3945], [RFC4206], and | ||||
[MLN-REQ]. | ||||
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 are three different layers. | |||
layers. A network comprising transport nodes with different data | A network comprising transport nodes with different data plane | |||
plane switching layers controlled by a single GMPLS control plane | switching layers controlled by a single GMPLS control plane instance | |||
instance is called a Multi-Layer Network (MLN). | 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 Label | |||
is defined in [RFC4206]. A network comprised of multiple switching | Switched Path (LSP) Region is defined in [RFC4206]. A network | |||
types (e.g. PSC and TDM) controlled by a single GMPLS control plane | comprised of multiple switching types (for example PSC and TDM) | |||
instance is called a Multi-Region Network (MRN). | controlled by a single GMPLS control plane 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 multiple data plane layers of the same switching | |||
within a region). Hence, in the following, we use the term layer if | technology. Hence, in the following, we use the term "layer" if the | |||
the mechanism discussed applies equally to layers and regions (e.g. | mechanism discussed applies equally to layers and regions (for | |||
VNT, virtual TE-link, etc.), and we specifically use the term region | example VNT, virtual TE-link, etc.), and we specifically use the term | |||
if the mechanism applies only for supporting a MRN. | "region" if the mechanism applies only to the support of a MRN. | |||
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], [RFC4202], [RFC3471]) against | mechanisms and protocols ([RFC 3945], [RFC4202], [RFC3471, | |||
the requirements for MLN and MRN, defined in [MLN-REQ]. From this | [RFC3473]]) against the requirements for MLN and MRN, defined in | |||
evaluation, we identify several areas where additional protocol | [MLN-REQ]. From this evaluation, we identify several areas where | |||
extensions and modifications are required to meet these requirements, | additional protocol extensions and modifications are required to meet | |||
and provide guidelines for potential extensions. | these requirements, and provide guidelines for potential extensions. | |||
An overview of MLN/MRN requirements is provided in section 3. Then | A summary of MLN/MRN requirements is provided in section 2. Then | |||
section 4 evaluates for each of these requirements, whether current | section 3 evaluates for each of these requirements, whether current | |||
GMPLS protocols and mechanisms allow addressing the requirements. | GMPLS protocols and mechanisms meet the requirements. When the | |||
When the requirements are not met, the document identifies whether | requirements are not met by existing protocols, the document | |||
the required mechanisms could rely on GMPLS protocols and procedure | identifies whether the required mechanisms could rely on GMPLS | |||
extensions or if it is entirely out of the scope of GMPLS protocols. | protocols and procedure extensions or whether 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. Partitions of the control plane where | |||
separate layers are under distinct administrative control are for | ||||
future study. | ||||
3. MLN/MRN Requirements Overview | This document uses terminologies defined in [RFC3945], [RFC4206], and | |||
[MLN-REQ]. | ||||
[MLN-REQ] lists a set of functional requirements for Multi | 2. MLN/MRN Requirements Overview | |||
Layer/Region Networks (MLN/MRN). These requirements are summarized | ||||
below: | ||||
- Support of robust Virtual Network Topology (VNT) | Section 5 of [MLN-REQ] lists a set of functional requirements for | |||
Multi Layer/Region Networks (MLN/MRN). These requirements are | ||||
summarized below, and a mapping with sub-sections of [MLN-REQ] is | ||||
provided. | ||||
Here is the list of requirements that apply to MLN: | ||||
- Support for 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 Forwarding Adjacency LSP (FA-LSP) | |||
- Support for virtual TE-links; | setup and release (section 5.8.1 of [MLN-REQ]); | |||
- Support for virtual TE-links (section 5.8.2 of [MLN- | ||||
REQ]); | ||||
- Traffic Disruption minimization during FA-LSP release | - Traffic Disruption minimization during FA-LSP release | |||
(e.g. network reconfiguration events); | (section 5.5 of [MLN-REQ]); | |||
- Stability; | - Stability (section 5.4 of [MLN-REQ]); | |||
- Support for FA-LSP attributes inheritance; | - Support for FA-LSP attributes inheritance (section 5.6 of | |||
[MLN-REQ]); | ||||
- Support for Triggered Signaling; | - Support for FA-LSP data plane connectivity verification | |||
(section 5.9 of [MLN-REQ]); | ||||
- Support for FA-LSP data plane connectivity verification; | Here is the list of requirements that apply to MRN only: | |||
- Support for Multi-Region signaling; | - Support for Multi-Region signaling (section 5.7 of [MLN-REQ]); | |||
- Advertisement of the adaptation capabilities and resources; | - Advertisement of the adaptation capabilities and resources | |||
(section 5.2 of [MLN-REQ]); | ||||
4. Analysis | 3. Analysis | |||
4.1. Multi-Layer Aspects | 3.1. Multi Layer Network Aspects | |||
4.1.1. Support for Virtual Network Topology Reconfiguration | 3.1.1. Support for Virtual Network Topology Reconfiguration | |||
A set of lower-layer FA-LSPs provides a Virtual Network Topology | A set of lower-layer FA-LSPs provides a Virtual Network Topology | |||
(VNT) to the upper-layer. By reconfiguring the VNT (FA-LSP | (VNT) to the upper-layer [MLN-REQ]. 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 within a layer, network performance factors | |||
as maximum link utilization and residual capacity of the network can | such as maximum link utilization and residual capacity of the network | |||
be optimized. Such optimal VNT reconfiguration implies several | can be optimized. Such optimal VNT reconfiguration implies several | |||
mechanisms that are analyzed in the following sections. | mechanisms that are analyzed in the following sections. | |||
Note that the VNT approach is just one approach among others, to | Note that the VNT approach is just one possible approach to perform | |||
perform inter-layer Traffic Engineering. | inter-layer Traffic Engineering. | |||
4.1.1.1. Control of FA-LSPs Setup/Release | 3.1.1.1. Control of FA-LSPs Setup/Release | |||
In a Multi-Layer Network, FA-LSPs are created, modified, released | In a Multi-Layer Network, FA-LSPs are created, modified, 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 and setup a new VNT. | |||
Several functional building blocks are required to support such TE | Several functional building blocks are required to support such TE | |||
mechanism: | 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 upper layer traffic demands. | |||
- VNT resources policing/scheduling with regards to traffic | - Policing and scheduling of VNT resources with regard to | |||
demands and usage (i.e. decision to setup/release FAs); The | traffic demands and usage (that is, decision to setup/release | |||
functional component in charge of this function is called a | FA-LSPs); The functional component in charge of this function | |||
VNT Manager (VNTM), it may be distributed on network | is called a VNT Manager (VNTM). | |||
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 | - VNT Paths Computation according to TE topology, and | |||
taking into account old VNT (to minimize changes); The | potentially taking into account the old (existing) VNT to | |||
Functional component in charge of VNT computation may be | minimize changes. The Functional component in charge of VNT | |||
distributed on network elements or may be centralized on an | computation may be distributed on network elements or may be | |||
external tool (such as e.g. a PCE). | centralized on an external tool (such as a Path Computation | |||
Element (PCE), [RFC4655]). | ||||
- FA-LSP setup/release. | - FA-LSP setup/release. | |||
GMPLS routing protocols support TE topology discovery. GMPLS | GMPLS routing protocols provide TE topology discovery. | |||
signaling protocols allow setting up/releasing FA-LSPs. | GMPLS 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-LSPs, FA-LSP configuration) are out of the scope of | |||
protocols. Such functionalities can be achieved directly on layer | GMPLS protocols. Such functionalities can be achieved directly on | |||
border LSRs, and/or on one or more external tools. When an external | layer border LSRs, or through one or more external tools. When an | |||
tool is used, an interface is required between the VNTM and network | external tool is used, an interface is required between the VNTM and | |||
elements so has to setup/releases FA-LSPs. This may rely on SNMP (TE | the network elements so as to setup/releases FA-LSPs. This could use | |||
MIB) or on proprietary interfaces. | standard management interfaces such as [RFC4802]. | |||
The set of traffic demands of the upper layer is required for the VNT | ||||
Manager to take decisions to setup/release FAs. This requires | ||||
knowledge of the aggregated bandwidth reserved by upper layer LSPs | ||||
established between any pair of border LSRs. | ||||
Existing GMPLS routing allows for the collection of traffic demands | ||||
of the upper region. It can be deduced from FA TE-link advertisements. | ||||
The set of traffic demands can be inferred: | ||||
- either directly, based on upper-layer FA TE-link advertisements. | ||||
The traffic demands between two points correspond to the | ||||
cumulated bandwidth reserved by upper-layer LSPs between these | ||||
two points; | ||||
- or indirectly, based on lower-layer FA TE-link advertisements. | ||||
In this case a mechanism to infer the upper-layer traffic demand | ||||
from the aggregated bandwidth reserved in lower-layer LSPs might | ||||
be required, as all pairs of border nodes may not be directly | ||||
connected by a lower layer LSP. | ||||
Collection of traffic demands of an upper region may actually be | The set of traffic demands of the upper layer is required for the | |||
achieved in several ways depending on the location of VNT Managers: | VNT Manager to take decisions to setup/release FA-LSPs. Such | |||
- If a VNTM is distributed on border layer LSRs, then the | traffic demands include satisfied demands, for which one or more | |||
collection of traffic demands would rely on existing GMPLS | upper layer LSP have been successfully satisfied, as well as | |||
routing, as per described above; | unsatisfied demands and future demands, for which no upper layer LSP | |||
- If a VNTM is centralized on an external tool, then the | has been setup yet. The collection of such information is beyond the | |||
collection of traffic demands may be achieved using existing | scope of GMPLS protocols, but may be partially inferred from | |||
GMPLS routing, provided that the tool relies on GMPLS routing to | parameters carried in GMPLS signaling or advertised in GMPLS routing. | |||
discover TE link information, or it may rely on another | ||||
mechanism out of the scope of GMPLS protocols (e.g. SNMP TE-link | ||||
MIB). | ||||
Finally, VNT computation can be performed directly on layer border | Finally, the computation of FA-LSPs that form the VNT can be | |||
LSRs or on an external tool (such as an external PCE) and this | performed directly on layer border LSRs or on an external tool (such | |||
independently of the location of the VNTM. VNT computation is | as a Path Computation Element (PCE), [RFC4655]), and this is | |||
triggered by the VNTM (e.g. when the Path computation is externalized | independent of the location of the VNTM. VNT computation is triggered | |||
on a PCE, the VNTM acts as PCC). | by the VNTM (for example, when the path computation is externalized | |||
on a PCE, the VNTM acts as Path Computation Client (PCC)). | ||||
Hence no GMPLS protocol extensions are required to control FA-LSP | Hence, to summarize, no GMPLS protocol extensions are required to | |||
setup/release. | control FA-LSP setup/release. | |||
4.1.1.2. Virtual TE-Links | 3.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 upper layer nodes that is | |||
associated to a fully provisioned FA-LSP. A Virtual TE-link | not actually associated with a fully provisioned FA-LSP in a lower | |||
represents the potentiality to setup a FA-LSP. There is no IGP | layer. A Virtual TE-link represents the potentiality to setup an FA- | |||
adjacency associated to a Virtual TE-link. A Virtual TE-link is | LSP in the lower layer to support the TE-link that has been | |||
advertised as any classical TE-link, i.e. following the rules in | advertised. A Virtual TE-link is advertised as any TE-link, following | |||
[RFC4206] defined for fully provisioned TE-links. Particularly, the | the rules in [RFC4206] defined for fully provisioned TE-links. In | |||
flooding scope of a Virtual TE-link is within an IGP area, as any TE- | particular, the flooding scope of a Virtual TE-link is within an IGP | |||
link. | area, as is the case for any TE-link. | |||
During its signalling, if an upper-layer LSP makes use of a Virtual | If an upper-layer LSP attempts (through a signalling message) to make | |||
TE-link, the underlying FA-LSP is immediately signalled and | use of a Virtual TE-link, the underlying FA-LSP is immediately | |||
provisioned. | signalled and provisioned in the process known as triggered | |||
signaling. | ||||
The use of Virtual TE-links has two main advantages: | The use of Virtual TE-links has two main advantages: | |||
- flexibility: allows to compute a LSP path using TE-links and this | - Flexibility: allows the computation of an LSP path using TE-links | |||
without taking into account the actual status of the | without needing to take into account the actual provisioning | |||
corresponding FA-LSP in the lower layer in terms of provisioning; | status of the corresponding FA-LSP in the lower layer; | |||
- stability: allows stability of TE-links in the upper layer, while | ||||
- Stability: allows stability of TE-links in the upper layer, while | ||||
avoiding wastage of bandwidth in the lower layer, as data plane | avoiding wastage of bandwidth in the lower layer, as data plane | |||
connections are not established. | connections are not established until they are actually needed. | |||
Virtual TE-links are setup/deleted/modified dynamically, according to | Virtual TE-links are setup/deleted/modified dynamically, according to | |||
the change of the (forecast) traffic demand, operator's policies for | the change of the (forecast) traffic demand, operator's policies for | |||
capacity utilization, and the available resources in the lower layer. | capacity utilization, and the available resources in the lower layer. | |||
The support of Virtual TE-links requires two main building blocks: | The support of Virtual TE-links requires two main building blocks: | |||
- A TE mechanism for dynamic modification of Virtual TE-link | - A TE mechanism for dynamic modification of Virtual TE-link | |||
Topology; | Topology; | |||
- A signalling mechanism for the dynamic setup and deletion of | ||||
- A signaling 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 | signaling 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 signalling does not allow setting up and releasing | Current GMPLS signalling does not allow setting up and releasing | |||
Virtual TE-links. Hence GMPLS signalling 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 | |||
in the control plane without actually activating cross connections in | control plane without actually activating cross connections in the | |||
the data plane. One the one hand, this requires state maintenance on | data plane. On the one hand, this requires state maintenance on all | |||
all transit LSRs (N square issue), but on the other hand this may | transit LSRs (N square issue), but on the other hand this may allow | |||
allow for some admission control. Indeed, when a soft-FA is | for some admission control. Indeed, when a soft-FA is activated, | |||
activated, there may be no longer available resources for other soft- | the resources may be no longer available for use by other soft-FAs | |||
FAs that were sharing common links, these soft-FA will be dynamically | that have common links. These soft-FA will be dynamically released | |||
released and corresponding virtual TE-links are deleted. The soft-FA | and corresponding virtual TE-links are deleted. The soft-FA LSPs | |||
LSPs may be setup using procedures similar to those described in | may be setup using procedures similar to those described in | |||
[GMPLS-RECOVERY] for setting up secondary LSPs. | [RFC4872] for setting up secondary LSPs. | |||
-The remote association approach, that simply consists of | - The remote association approach that simply consists of exchanging | |||
exchanging virtual TE-links ids and parameters directly between TE- | virtual TE-links IDs and parameters directly between TE-link end | |||
link end points. This does not require state maintenance on transit | points. This does not require state maintenance on transit LSRs, | |||
LSRs, but reduce admission control capabilities. Such an association | but reduces admission control capabilities. Such an association | |||
between Virtual TE-link end-points may rely on extensions to the | between Virtual TE-link end-points may rely on extensions to the | |||
RSVP-TE ASON Call procedure ([ASON-CALL]). | RSVP-TE ASON Call procedure ([RSVP-CALL]). | |||
Note that the support of Virtual TE-link does not require any GMPLS | Note that the support of Virtual TE-links does not require any GMPLS | |||
routing extension. | routing extension. | |||
4.1.1.3. Traffic Disruption Minimization During FA Release | 3.1.1.3. Traffic Disruption Minimization During FA Release | |||
Before deleting a given FA-LSP, all nested LSPs have to be rerouted | Before deleting a given FA-LSP, all nested LSPs have to be rerouted | |||
and removed from the FA-LSP to avoid traffic disruption. | and removed from the FA-LSP to avoid traffic disruption. | |||
The 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 | |||
allows for the deletion of a TE-link without disrupting traffic of | allows for the deletion of a TE-link without disrupting traffic of | |||
TE-LSPs that where using the TE-link. | TE-LSPs that were using the TE-link. | |||
GMPLS protocols do not provide for explicit indication to trigger | ||||
such operation. | ||||
Hence, GMPLS routing and/or signaling extensions are required | Hence, GMPLS routing and/or signaling extensions are required | |||
to support graceful deletion of TE-links. This may rely, for | to support graceful deletion of TE-links. This may utilize the | |||
instance, on new signaling Error code to notify head-end LSRs that a | procedures described in [GR-SHUT]: A transit LSR notifies a head-end | |||
TE-link along the path of a LSP is going to disappear, and also on | LSR that a TE-link along the path of a LSP is going to be torn down, | |||
new routing attributes (if limited to a single IGP area), such as | and also withdraws the bandwidth on the TE-link so that it is not | |||
defined in [GR-SHUT]. | used for new LSPs. | |||
4.1.1.4. Stability | 3.1.1.4. Stability | |||
The upper-layer LSP stability may be impaired if the VNT undergoes | The stability of upper-layer LSP may be impaired if the VNT undergoes | |||
frequent changes. In this context robustness of the VNT is defined as | frequent changes. In this context robustness of the VNT is defined as | |||
the capability to smooth impact of these changes and avoid their | the capability to smooth the impact of these changes and avoid their | |||
subsequent propagation. | subsequent propagation. | |||
Guaranteeing VNT stability is out of the scope of GMPLS protocols and | Guaranteeing VNT stability is out of the scope of GMPLS protocols and | |||
relies entirely on the capability of TE algorithms to minimize | relies entirely on the capability of the TE and VNT management | |||
routing perturbations. This requires that the TE algorithm takes into | algorithms to minimize routing perturbations. This requires that the | |||
account the old VNT when computing a new VNT, and tries to minimize | algorithms takes into account the old VNT when computing a new VNT, | |||
the perturbation. | and try to minimize the perturbation. | |||
4.1.2. Support for FA-LSP Attributes Inheritance | ||||
When FA TE-link parameters are inherited from FA-LSP parameters, | ||||
specific inheritance rules are applied. | ||||
This relies on local procedures and policies and is out of the scope | ||||
of GMPLS protocols. | ||||
Note that this requires that both head-end and tail-end of the FA-LSP | ||||
are driven by same policies. | ||||
4.1.3. Support for Triggered Signaling. | ||||
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 | ||||
does not exist the LSP may be established dynamically. Such a | ||||
mechanism is referred to as "Triggered signaling". | ||||
Triggered signaling requires the following building blocks: | A full mesh of upper-layer LSPs MAY be created between every pair of | |||
- The identification of layer boundaries. | border nodes between the upper and lower layers. The merit of a full | |||
- A path computation engine capable of computing a path | mesh of upper-layer LSPs is that it provides stability to the upper | |||
containing multiple layers. | layer routing. That is, forwarding table used in the upper layer is | |||
not impacted if the VNT undergoes changes. Further, there is always | ||||
full reachability and immediate access to bandwidth to support LSPs | ||||
in the upper layer. But it also has significant drawbacks, since it | ||||
requires the maintenance of n^2 RSVP-TE sessions, which may be quite | ||||
CPU and memory consuming (scalability impact). Also this may lead to | ||||
significant bandwidth wastage. Note that the use of virtual TE-links | ||||
solves the bandwidth wastage issue, and may reduce the control plane | ||||
overload. | ||||
- A mechanism for nested signaling. | 3.1.2. Support for FA-LSP Attributes Inheritance | |||
The identification of layer boundaries is supported by GMPLS routing | When a FA TE Link is advertised, its parameters are inherited from | |||
protocols. The identification of layer boundaries is performed using | the parameters of the FA-LSP, and specific inheritance rules are | |||
the interface switching capability descriptor associated to the TE- | applied. | |||
link (see [RFC4206] and [RFC4202]). | ||||
The capability to compute a path containing multiple layers is a | This relies on local procedures and policies and is out of the scope | |||
local implementation issue and is out of the scope of GMPLS protocols. | of GMPLS protocols. Note that this requires that both head-end and | |||
tail-end of the FA-LSP are driven by same policies. | ||||
A mechanism for nested signaling is defined in [RFC4206]. | 3.1.3. FA-LSP Connectivity Verification | |||
Hence, GMPLS protocols already meet this requirement. | Once fully provisioned, FA-LSP liveliness may be achieved by | |||
verifying its data plane connectivity. | ||||
4.1.4. FA Connectivity Verification | FA-LSP connectivity verification relies on technology specific | |||
mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using BFD; | ||||
etc.) as for any other LSP. Hence this requirement is out of the | ||||
scope of GMPLS protocols. | ||||
Once fully provisioned, FA liveliness may be achieved by verifying | 3.2. Specific Aspects for Multi-Region Networks | |||
its data plane connectivity. | ||||
FA connectivity verification relies on technology specific mechanisms | 3.2.1. Support for Multi-Region Signaling | |||
(e.g. for SDH, G.707, G.783, for MPLS, BFD, etc.) as for any other | ||||
LSP. Hence this requirement is out of the scope of GMPLS protocols. | ||||
Note that the time to establish the FA-LSP must be minimized. | There are actually several cases where a transit node could choose | |||
between multiple SCs to be used for a lower region FA-LSP: | ||||
4.2. Multi-Region Specific Aspects | - ERO expansion with loose hops: The transit node has to expand the | |||
path, and may have to select among a set of lower region SCs. | ||||
4.2.1. Support for Multi-Region Signaling | - Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of | |||
an upper region LSP, comprises a multi-SC TE-link, the region | ||||
border node has to select among these SCs. | ||||
Applying the triggered signaling procedure discussed above, in a MRN | Existing GMPLS signalling procedures does not allow solving this | |||
environment may lead to the setup of one-hop FA-LSPs between each | ambiguous choice of SC that may be used along a given path. | |||
node. Therefore, considering that the path computation is able to | ||||
take into account richness of information with regard to the | ||||
Switching Capability (SC) available on given nodes belonging to the | ||||
path, it is consistent to provide enough signaling information to | ||||
indicate the SC to be used and on over which link. | ||||
Limited extension to existing GMPLS signaling procedures is required | Hence an extension to GMPLS signalling has to be defined to indicate | |||
for this purpose as it only mandates indication of the SCs to be | the SC(s) that can be used and the SC(s) that cannot be used along | |||
included or excluded before initiating the LSP provisioning procedure. | the path. | |||
This enhancement would solve the ambiguous choice of SC that are | ||||
potentially used along a given path, particularly in case of ERO | ||||
expansion, or when an ERO sub-object identifies a multi-SC TE-link. | ||||
This would give the possibility to optimize resource usage on a | ||||
multi-region basis. | ||||
4.2.2. Advertisement of Internal Adaptation Capabilities | 3.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 ([MLN- | |||
nodes contain at least two distinct switching elements that are | REQ]). Hybrid nodes contain at least two distinct switching elements | |||
interconnected by internal links to provide adaptation between the | that are interconnected by internal links to provide adaptation | |||
supported switching capabilities. These internal links have finite | between the supported switching capabilities. These internal links | |||
capacities and must be taken into account when computing the path of | have finite capacities and must be taken into account when computing | |||
a multi-region TE-LSP. The advertisement of the internal adaptation | the path of a multi-region TE-LSP. The advertisement of the internal | |||
capability is required as it provides critical information when | adaptation capability is required as it provides critical information | |||
performing multi-region path computation. | when performing multi-region path 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 | |||
possible to set up PSC LSPs (port 1 or port 2). Available resources | possible to set up PSC LSPs (port 1 or port 2). Available resources | |||
advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover | advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover | |||
both ways. | both ways. | |||
Network element | Network element | |||
............................. | ............................. | |||
skipping to change at page 10, line 34 | skipping to change at page 10, line 9 | |||
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 | |||
possible to set up PSC LSPs (port 1 or port 2). Available resources | possible to set up PSC LSPs (port 1 or port 2). Available resources | |||
advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover | advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover | |||
both ways. | both ways. | |||
Network element | Network element | |||
............................. | ............................. | |||
: -------- : | : -------- : | |||
PSC : | PSC | : | PSC : | PSC | : | |||
Port1-------------<->--|#a | : | Port1-------------<->---|#a | : | |||
: +--<->---|#b | : | : +--<->---|#b | : | |||
: | -------- : | : | -------- : | |||
TDM : | ---------- : | TDM : | ---------- : | |||
+PSC : +--<->--|#c TDM | : | +PSC : +--<->--|#c TDM | : | |||
Port2 ------------<->--|#d | : | Port2 ------------<->--|#d | : | |||
: ---------- : | : ---------- : | |||
:............................ | :............................ | |||
Figure 1a. Hybrid node. | Figure 1a. Hybrid node. | |||
skipping to change at page 11, line 47 | skipping to change at page 11, line 17 | |||
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 [RFC4202] this advertisement is possible | With current GMPLS routing [RFC4202] this advertisement is possible | |||
if link bundling is not used and if two TE-links are advertised for | if link bundling is not used and if two TE-links are advertised for | |||
link1: | link1: | |||
We would have the following TE-link advertisements: | We would have the following TE-link advertisements: | |||
TE-link 1 (port 1): | TE-link 1 (port 1): | |||
- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb, unreserved | - ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb | |||
bandwidth = 622Mb. | - Unreserved 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. | ||||
- 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 (equivalent): 777 Mb. | |||
The ISCD 2 in TE-link 2 represents actually the internal TDM-PSC | The ISCD 2 in TE-link 2 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. | ||||
- 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 (equivalent): 1399 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 capability | could rely on the advertisement of the internal adaptation capability | |||
as a new TE link attribute (that would complement the Interface | as a new TE link attribute (that would complement the Interface | |||
Switching Capability Descriptor TE-link attribute). | Switching Capability Descriptor TE-link attribute). | |||
5. Evaluation Conclusion | Note: Multiple ISCDs MAY be associated to a single switching | |||
capability. This can be performed to provide e.g. for TDM interfaces | ||||
the Min/Max LSP Bandwidth associated to each (set of) layer for that | ||||
switching capability. As an example, an interface associated to TDM | ||||
switching capability and supporting VC-12 and VC-4 switching, can be | ||||
associated one ISCD sub-TLV or two ISCD sub-TLVs. In the first case, | ||||
the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to | ||||
VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and | ||||
the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the | ||||
Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4, | ||||
in the second ISCD sub-TLV. Hence, in the first case, as long as the | ||||
Min LSP Bandwidth is set to VC-12 (and not VC-4) and in the second | ||||
case, as long as the first ISCD sub-TLV is advertised there is | ||||
sufficient capacity across that interface to setup a VC-12 LSP." | ||||
4. Evaluation Conclusion | ||||
Most of the required MLN/MRN functions will rely on mechanisms and | Most of the required MLN/MRN functions will rely on mechanisms and | |||
procedures that are out of the scope of the GMPLS protocols, and thus | procedures that are out of the scope of the GMPLS protocols, and thus | |||
do not require any GMPLS protocol extensions. They will rely on local | do not require any GMPLS protocol extensions. They will rely on 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 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 signalling extension for the setup/deletion of | - GMPLS signaling extension for the setup/deletion of | |||
the virtual TE-links (as well as exact trigger for its actual | the virtual TE-links; | |||
provisioning); | ||||
- GMPLS routing and signalling extension for graceful TE-link | - GMPLS routing and signaling extension for graceful TE-link | |||
deletion; | deletion; | |||
- GMPLS signalling extension for constrained multi-region | - GMPLS signaling extension for constrained multi-region | |||
signalling (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 | 5. 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]. | |||
7. Acknowledgments | 6. Acknowledgments | |||
We would like to thank Julien Meuric and Igor Bryskin for their | We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel | |||
useful comments. | for their useful comments. | |||
8. References | 7. References | |||
8.1. Normative | 7.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 | |||
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing | [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing | |||
Extensions in Support of Generalized Multi-Protocol Label Switching", | Extensions in Support of Generalized Multi-Protocol | |||
draft-ietf-ccamp-gmpls-routing, RFC4202, October 2005. | Label Switching", draft-ietf-ccamp-gmpls-routing, | |||
RFC4202, October 2005. | ||||
[RFC3471] 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 | |||
January 2003. | 3471, January 2003. | |||
8.2. Informative | 7.2. Informative | |||
[ASON-CALL] Papadimitriou, D., Farrel, A., et. al., "Generalized MPLS | [RSVP-CALL] Papadimitriou, D., Farrel, A., et. al., "Generalized | |||
(GMPLS) RSVP-TE Signaling Extensions in support of Calls", draft- | MPLS (GMPLS) RSVP-TE Signaling Extensions in support of | |||
ietf-ccamp-gmpls-rsvp-te-call, work in progress. | Calls", draft-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., | |||
M., Brungard, D., "Requirements for GMPLS-based multi-region and | Vigoureux, M., Brungard, D., "Requirements for GMPLS- | |||
multi-layer networks", draft-ietf-ccamp-gmpls-mrn-reqs, work in | based multi-region and multi-layer networks", draft- | |||
progess. | ietf-ccamp-gmpls-mrn-reqs, work in progess. | |||
[RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized | [RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with | |||
MPLS TE", draft-ietf-mpls-lsp-hierarchy, RFC4206, October 2005. | generalized 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-ietf-ccamp-mpls-graceful-shutdown, work | Engineering Network", draft-ietf-ccamp-mpls-graceful- | |||
in progress. | shutdown, work in progress. | |||
[GMPLS-RECOVERY] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in | [RFC4872] 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 | |||
(GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e- | Switching (GMPLS)-based Recovery", RFC4872, July 2007. | |||
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 | |||
Traffic Engineering", draft-oki-pce-vntm-def, work in progress. | and GMPLS 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", | |||
ccamp-mpls-gmpls-interwork-fmwk, work in progress. | draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in | |||
progress. | ||||
9. Authors' Addresses: | [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions", | |||
RFC3473, January 2003. | ||||
Jean-Louis Le Roux (Editor) | [RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based | |||
Architecture", RFC4655, August 2006. | ||||
[RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802, | ||||
February 2007. | ||||
8. Editors' Addresses | ||||
Jean-Louis Le Roux | ||||
France Telecom | France Telecom | |||
2, avenue Pierre-Marzin | 2, avenue Pierre-Marzin | |||
22307 Lannion Cedex, France | 22307 Lannion Cedex, France | |||
Email: jeanlouis.leroux@orange-ft.com | Email: jeanlouis.leroux@orange-ftgroup.com | |||
Dimitri Papadimitriou | ||||
Alcatel-Lucent | ||||
Francis Wellensplein 1, | ||||
B-2018 Antwerpen, Belgium | ||||
Email: dimitri.papadimitriou@alcatel-lucent.be | ||||
9. Contributors' Addresses | ||||
Deborah Brungard | Deborah Brungard | |||
AT&T | AT&T | |||
Rm. D1-3C22 - 200 S. Laurel Ave. | Rm. D1-3C22 - 200 S. Laurel Ave. | |||
Middletown, NJ, 07748 USA | Middletown, NJ, 07748 USA | |||
E-mail: dbrungard@att.com | 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 | |||
Email: oki.eiji@lab.ntt.co.jp | Email: oki.eiji@lab.ntt.co.jp | |||
Dimitri Papadimitriou | ||||
Alcatel | ||||
Francis Wellensplein 1, | ||||
B-2018 Antwerpen, Belgium | ||||
Email: dimitri.papadimitriou@alcatel.be | ||||
Kohei Shiomoto | Kohei Shiomoto | |||
NTT | NTT | |||
3-9-11 Midori-Cho | 3-9-11 Midori-Cho | |||
Musashino, Tokyo 180-8585, Japan | Musashino, Tokyo 180-8585, Japan | |||
Email: shiomoto.kohei@lab.ntt.co.jp | Email: shiomoto.kohei@lab.ntt.co.jp | |||
Martin Vigoureux | ||||
Alcatel | M. Vigoureux | |||
Route de Nozay, | Alcatel-Lucent France | |||
91461 Marcoussis Cedex, France | Route de Villejust | |||
Email: martin.vigoureux@alcatel.fr | 91620 Nozay | |||
FRANCE | ||||
Email: martin.vigoureux@alcatel-lucent.fr | ||||
10. Intellectual Property Statement | 10. Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
skipping to change at page 15, line 31 | skipping to change at page 15, line 27 | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. | |||
ietf-ipr@ietf.org. | ||||
Disclaimer of Validity | Disclaimer of Validity | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | |||
FOR A PARTICULAR PURPOSE. | ||||
Copyright Statement | Copyright Statement | |||
Copyright (C) The Internet Society (2006). This document is subject | Copyright (C) The IETF Trust (2007). This document is subject to the | |||
to the rights, licenses and restrictions contained in BCP 78, and | rights, licenses and restrictions contained in BCP 78, and except as | |||
except as set forth therein, the authors retain all their rights. | set forth therein, the authors retain all their rights. | |||
End of changes. 107 change blocks. | ||||
328 lines changed or deleted | 329 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/ |