draft-ietf-ccamp-gmpls-mln-eval-04.txt   draft-ietf-ccamp-gmpls-mln-eval-05.txt 
Network Working Group J.L. Le Roux (Ed.) Network Working Group J.L. Le Roux (Ed.)
Internet Draft France Telecom Internet Draft France Telecom
Category: Informational Category: Informational
Expires: May 2008 D. Papadimitriou (Ed.) Created: December 17, 2007 D. Papadimitriou (Ed.)
Alcatel-Lucent Expires: June 17, 2008 Alcatel-Lucent
November 2007
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-04.txt draft-ietf-ccamp-gmpls-mln-eval-05.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 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction................................................3 1. Introduction................................................3
2. MLN/MRN Requirements Overview...............................4 2. MLN/MRN Requirements Overview...............................4
3. Analysis....................................................4 3. Analysis....................................................4
3.1. Multi Layer Network Aspects.................................4 3.1. Multi Layer Network Aspects.................................4
3.1.1. Support for Virtual Network Topology Reconfiguration........4 3.1.1. Support for Virtual Network Topology Reconfiguration........4
3.1.1.1. Control of FA-LSPs Setup/Release..........................5 3.1.1.1. Control of FA-LSPs Setup/Release..........................5
3.1.1.2. Virtual TE-Links..........................................6 3.1.1.2. Virtual TE-Links..........................................6
3.1.1.3. Traffic Disruption Minimization During FA Release.........7 3.1.1.3. Traffic Disruption Minimization During FA Release.........7
3.1.1.4. Stability.................................................7 3.1.1.4. Stability.................................................8
3.1.2. Support for FA-LSP Attributes Inheritance...................8 3.1.2. Support for FA-LSP Attributes Inheritance...................8
3.1.3. FA-LSP Connectivity Verification............................8 3.1.3. FA-LSP Connectivity Verification............................8
3.2. Specific Aspects for Multi-Region Networks..................8 3.2. Specific Aspects for Multi-Region Networks..................9
3.2.1. Support for Multi-Region Signaling..........................8 3.2.1. Support for Multi-Region Signaling..........................9
3.2.2. Advertisement of Adjustment Capacities......................9 3.2.2. Advertisement of Adjustment Capacities......................9
4. Evaluation Conclusion......................................12 4. Evaluation Conclusion......................................12
5. Security Considerations....................................12 5. Security Considerations....................................13
6. Acknowledgments............................................13 6. IANA Considerations........................................13
7. References.................................................13 7. Acknowledgments............................................13
7.1. Normative..................................................13 8. References.................................................13
7.2. Informative................................................13 8.1. Normative References.......................................13
8. Editors' Addresses:........................................14 8.2. Informative References.....................................14
9. Contributors' Addresses:...................................14 9. Editors' Addresses:........................................14
10. Intellectual Property Statement............................15 10. Contributors' Addresses:...................................15
11. Intellectual Property Statement............................15
1. Introduction 1. Introduction
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching Generalized MPLS (GMPLS) extends MPLS to handle multiple switching
technologies: packet switching, layer-2 switching, TDM switching, technologies: packet switching, layer-2 switching, TDM switching,
wavelength switching, and fiber switching (see [RFC3945]). The wavelength switching, and fiber switching (see [RFC3945]). The
Interface Switching Capability (ISC) concept is introduced for Interface Switching Capability (ISC) concept is introduced for
these switching technologies and is designated as follows: PSC these switching technologies and is designated as follows: PSC
(Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM (Time (Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM (Time
Division Multiplex capable), LSC (Lambda Switch Capable), and FSC Division Multiplex capable), LSC (Lambda Switch Capable), and FSC
(Fiber Switch Capable). The representation, in a GMPLS control (Fiber Switch Capable). The representation, in a GMPLS control
plane, of a switching technology domain is referred to as a region plane, of a switching technology domain is referred to as a region
[RFC4206]. A switching type describes the ability of a node to [RFC4206]. A switching type describes the ability of a node to
forward data of a particular data plane technology, and uniquely forward data of a particular data plane technology, and uniquely
identifies a network region. identifies a network region.
A data plane switching layer describes a data plane switching A data plane switching layer describes a data plane switching
granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are
three different layers. [MLN-REQ] defines a Multi Layer Network (MLN) three different layers. [MLN-REQ] defines a Multi Layer Network
to be a TE domain comprising multiple data plane switching layers (MLN) to be a TE domain comprising multiple data plane switching
either of the same ISC (e.g. TDM) or different ISC (e.g. TDM and layers either of the same ISC (e.g. TDM) or different ISC (e.g. TDM
PSC) and controlled by a single GMPLS control plane instance. and PSC) and controlled by a single GMPLS control plane instance.
[MLN-REQ] further define a particular case of MLNs. A Multi Region [MLN-REQ] further define a particular case of MLNs. A Multi Region
Network (MRN) is defined as a TE domain supporting at least two Network (MRN) is defined as a TE domain supporting at least two
different switching types (e.g., PSC and TDM), either hosted on the different switching types (e.g., PSC and TDM), either hosted on the
same device or on different ones, and under the control of a single same device or on different ones, and under the control of a single
GMPLS control plane instance. GMPLS control plane instance.
The objectives of this document are to evaluate existing GMPLS The objectives of this document are to evaluate existing GMPLS
mechanisms and protocols ([RFC 3945], [RFC4202], [RFC3471, mechanisms and protocols ([RFC3945], [RFC4202], [RFC3471],
[RFC3473]]) against the requirements for MLN and MRN, defined in [RFC3473]) against the requirements for MLN and MRN, defined in
[MLN-REQ]. From this evaluation, we identify several areas where [MLN-REQ]. From this evaluation, we identify several areas where
additional protocol extensions and modifications are required to meet additional protocol extensions and modifications are required to meet
these requirements, and provide guidelines for potential extensions. these requirements, and provide guidelines for potential extensions.
A summary of MLN/MRN requirements is provided in section 2. Then A summary of MLN/MRN requirements is provided in section 2. Then
section 3 evaluates for each of these requirements, whether current section 3 evaluates for each of these requirements, whether current
GMPLS protocols and mechanisms meet the requirements. When the GMPLS protocols and mechanisms meet the requirements. When the
requirements are not met by existing protocols, the document requirements are not met by existing protocols, the document
identifies whether the required mechanisms could rely on GMPLS identifies whether the required mechanisms could rely on GMPLS
protocols and procedure extensions or whether it is entirely out of protocols and procedure extensions or whether it is entirely out of
skipping to change at page 4, line 14 skipping to change at page 4, line 14
2. MLN/MRN Requirements Overview 2. MLN/MRN Requirements Overview
Section 5 of [MLN-REQ] lists a set of functional requirements for Section 5 of [MLN-REQ] lists a set of functional requirements for
Multi Layer/Region Networks (MLN/MRN). These requirements are Multi Layer/Region Networks (MLN/MRN). These requirements are
summarized below, and a mapping with sub-sections of [MLN-REQ] is summarized below, and a mapping with sub-sections of [MLN-REQ] is
provided. provided.
Here is the list of requirements that apply to MLN (and thus to MRN): Here is the list of requirements that apply to MLN (and thus to MRN):
- Support for robust Virtual Network Topology (VNT) - Support for robust Virtual Network Topology (VNT) reconfiguration.
reconfiguration. This implies the following requirements: This implies the following requirements:
- Optimal control of Forwarding Adjacency LSP (FA-LSP)
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
(section 5.5 of [MLN-REQ]);
- Stability (section 5.4 of [MLN-REQ]);
- Support for FA-LSP attributes inheritance (section 5.6 of - Optimal control of Forwarding Adjacency LSP (FA-LSP) 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 (Section
5.5 of [MLN-REQ]);
- Stability (Section 5.4 of [MLN-REQ]);
- Support for FA-LSP attributes inheritance (Section 5.6 of
[MLN-REQ]); [MLN-REQ]);
- Support for FA-LSP data plane connectivity verification - Support for FA-LSP data plane connectivity verification
(section 5.9 of [MLN-REQ]); (Section 5.9 of [MLN-REQ]);
Here is the list of requirements that apply to MRN only: Here is the list of requirements that apply to MRN only:
- Support for Multi-Region signaling (section 5.7 of [MLN-REQ]); - Support for Multi-Region signaling (section 5.7 of [MLN-REQ]);
- Advertisement of the adjustment capacity (section 5.2 of - Advertisement of the adjustment capacity (section 5.2 of
[MLN-REQ]); [MLN-REQ]);
3. Analysis 3. Analysis
skipping to change at page 5, line 22 skipping to change at page 5, line 22
matrix, the TE topology and potentially the current VNT, in order to matrix, the TE topology and potentially the current VNT, in order to
compute and setup a new VNT. compute and setup a new VNT.
Several functional building blocks are required to support such TE Several functional building blocks are required to support such TE
mechanism: mechanism:
- Discovery of TE topology and available resources. - Discovery of TE topology and available resources.
- Collection of upper layer traffic demands. - Collection of upper layer traffic demands.
- Policing and scheduling of VNT resources with regard to - Policing and scheduling of VNT resources with regard to traffic
traffic demands and usage (that is, decision to setup/release demands and usage (that is, decision to setup/release FA-LSPs). The
FA-LSPs); The functional component in charge of this function functional component in charge of this function is called a VNT
is called a VNT Manager (VNTM). Manager (VNTM) [PCE-INTER].
- VNT Paths Computation according to TE topology, and - VNT Paths Computation according to TE topology, and potentially
potentially taking into account the old (existing) VNT to taking into account the old (existing) VNT to minimize changes. The
minimize changes. The Functional component in charge of VNT Functional component in charge of VNT computation may be
computation may be distributed on network elements or may be distributed on network elements or may be performed on an external
performed on an external tool (such as a Path Computation tool (such as a Path Computation Element (PCE), [RFC4655]).
Element (PCE), [RFC4655]).
- FA-LSP setup/release. - FA-LSP setup/release.
GMPLS routing protocols provide TE topology discovery. GMPLS routing protocols provide TE topology discovery.
GMPLS signaling protocols allow setting up/releasing FA-LSPs. GMPLS signaling protocols allow setting up/releasing FA-LSPs.
VNTM functions (resources policing/scheduling, decision to VNTM functions (resources policing/scheduling, decision to
setup/release FA-LSPs, FA-LSP configuration) are out of the scope of setup/release FA-LSPs, FA-LSP configuration) are out of the scope of
GMPLS protocols. Such functionalities can be achieved directly on GMPLS protocols. Such functionalities can be achieved directly on
layer border LSRs, or through one or more external tools. When an layer border LSRs, or through one or more external tools. When an
skipping to change at page 5, line 54 skipping to change at page 5, line 53
the network elements so as to setup/release FA-LSPs. This could use the network elements so as to setup/release FA-LSPs. This could use
standard management interfaces such as [RFC4802]. standard management interfaces such as [RFC4802].
The set of traffic demands of the upper layer is required for the The set of traffic demands of the upper layer is required for the
VNT Manager to take decisions to setup/release FA-LSPs. Such VNT Manager to take decisions to setup/release FA-LSPs. Such
traffic demands include satisfied demands, for which one or more traffic demands include satisfied demands, for which one or more
upper layer LSP have been successfully setup, as well as unsatisfied upper layer LSP have been successfully setup, as well as unsatisfied
demands and future demands, for which no upper layer LSP has been demands and future demands, for which no upper layer LSP has been
setup yet. The collection of such information is beyond the scope of setup yet. The collection of such information is beyond the scope of
GMPLS protocols. Note that it may be partially inferred from GMPLS protocols. Note that it may be partially inferred from
parameters carried in GMPLS signalling or advertised in GMPLS routing. parameters carried in GMPLS signalling or advertised in GMPLS
routing.
Finally, the computation of FA-LSPs that form the VNT can be Finally, the computation of FA-LSPs that form the VNT can be
performed directly on layer border LSRs or on an external tool (such performed directly on layer border LSRs or on an external tool (such
as a Path Computation Element (PCE), [RFC4655]), and this is as a Path Computation Element (PCE), [RFC4655]), and this is
independent of the location of the VNTM. independent of the location of the VNTM.
Hence, to summarize, no GMPLS protocol extensions are required to Hence, to summarize, no GMPLS protocol extensions are required to
control FA-LSP setup/release. control FA-LSP setup/release.
3.1.1.2. Virtual TE-Links 3.1.1.2. Virtual TE-Links
skipping to change at page 6, line 32 skipping to change at page 6, line 32
area, as is the case for any TE-link. area, as is the case for any TE-link.
If an upper-layer LSP attempts (through a signalling message) to make If an upper-layer LSP attempts (through a signalling message) to make
use of a Virtual TE-link, the underlying FA-LSP is immediately use of a Virtual TE-link, the underlying FA-LSP is immediately
signalled and provisioned (provided there are available resources in signalled and provisioned (provided there are available resources in
the lower layer) in the process known as triggered signaling. the lower layer) in the process known as triggered signaling.
The use of Virtual TE-links has two main advantages: The use of Virtual TE-links has two main advantages:
- Flexibility: allows the computation of an LSP path using TE-links - Flexibility: allows the computation of an LSP path using TE-links
without needing to take into account the actual provisioning without needing to take into account the actual provisioning status
status of the corresponding FA-LSP in the lower layer; of the corresponding FA-LSP in the lower layer;
- Stability: allows stability of TE-links in the upper layer, while - Stability: allows stability of TE-links in the upper layer, while
avoiding wastage of bandwidth in the lower layer, as data plane avoiding wastage of bandwidth in the lower layer, as data plane
connections are not established until they are actually needed. connections are not established until they are actually needed.
Virtual TE-links are setup/deleted/modified dynamically, according to Virtual TE-links are setup/deleted/modified dynamically, according to
the change of the (forecast) traffic demand, operator's policies for the change of the (forecast) traffic demand, operator's policies for
capacity utilization, and the available resources in the lower layer. capacity utilization, and the available resources in the lower layer.
The support of Virtual TE-links requires two main building blocks: The support of Virtual TE-links requires two main building blocks:
- A TE mechanism for dynamic modification of Virtual TE-link - A TE mechanism for dynamic modification of Virtual TE-link
Topology; Topology;
- A signaling mechanism for the dynamic setup and deletion of - A signaling mechanism for the dynamic setup and deletion of virtual
virtual TE-links. Setting up a virtual TE-link requires a TE-links. Setting up a virtual TE-link requires a signaling
signaling mechanism allowing an end-to-end association mechanism allowing an end-to-end association between Virtual
between Virtual TE-link end points so as to exchange link TE-link end points so as to exchange link identifiers as well as
identifiers as well as some TE parameters. 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:
skipping to change at page 7, line 27 skipping to change at page 7, line 29
that have common links. These soft-FA will be dynamically released that have common links. These soft-FA will be dynamically released
and corresponding virtual TE-links are deleted. The soft-FA LSPs and corresponding virtual TE-links are deleted. The soft-FA LSPs
may be setup using procedures similar to those described in may be setup using procedures similar to those described in
[RFC4872] for setting up secondary LSPs. [RFC4872] for setting up secondary LSPs.
- The remote association approach that simply consists of exchanging - The remote association approach that simply consists of exchanging
virtual TE-links IDs and parameters directly between TE-link end virtual TE-links IDs and parameters directly between TE-link end
points. This does not require state maintenance on transit LSRs, points. This does not require state maintenance on transit LSRs,
but reduces admission control capabilities. Such an association but reduces admission control capabilities. Such an association
between Virtual TE-link end-points may rely on extensions to the between Virtual TE-link end-points may rely on extensions to the
RSVP-TE ASON Call procedure ([RSVP-CALL]). RSVP-TE ASON Call procedure ([RFC4974]).
Note that the support of Virtual TE-links does not require any GMPLS Note that the support of Virtual TE-links does not require any GMPLS
routing extension. routing extension.
3.1.1.3. Traffic Disruption Minimization During FA Release 3.1.1.3. Traffic Disruption Minimization During FA Release
Before deleting a given FA-LSP, all nested LSPs have to be rerouted Before deleting a given FA-LSP, all nested LSPs have to be rerouted
and removed from the FA-LSP to avoid traffic disruption. and removed from the FA-LSP to avoid traffic disruption.
The 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 12, line 23 skipping to change at page 12, line 37
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 need to be defined, but these reconfiguration, specific TE mechanisms need to be defined, but these
mechanisms are out of the scope of GMPLS protocols. mechanisms are out of the scope of GMPLS protocols.
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 signaling extension for the setup/deletion of the virtual
the virtual TE-links; TE-links;
- GMPLS routing and signaling extension for graceful TE-link - GMPLS routing and signaling extension for graceful TE-link
deletion; deletion;
- GMPLS signaling extension for constrained multi-region - GMPLS signaling extension for constrained multi-region signalling
signalling (SC inclusion/exclusion); (SC inclusion/exclusion);
- GMPLS routing extension for the advertisement of the - GMPLS routing extension for the advertisement of the adjustment
adjustment capacities of hybrid nodes. capacities of hybrid nodes.
5. Security Considerations 5. Security Considerations
[MLN-REQ] sets out the security requirements for operating a MLN or [MLN-REQ] sets out the security requirements for operating a MLN or
MRN. These requirements are, in general, no different from the MRN. These requirements are, in general, no different from the
security requirements for operating any GMPLS network. As such, the security requirements for operating any GMPLS network. As such, the
GMPLS protocols already provide adequate security features. An GMPLS protocols already provide adequate security features. An
evaluation of the security features for GMPLS networks may be found evaluation of the security features for GMPLS networks may be found
in [MPLS-SEC], and where issues or further work is identified by that in [MPLS-SEC], and where issues or further work is identified by that
document, new security features or procedures for the GMPLS protocols document, new security features or procedures for the GMPLS protocols
skipping to change at page 13, line 9 skipping to change at page 13, line 27
network are operated as different administrative domains, additional network are operated as different administrative domains, additional
security considerations may be given to the mechanisms for allowing security considerations may be given to the mechanisms for allowing
inter-layer LSP setup. However, this document is explicitly limited inter-layer LSP setup. However, this document is explicitly limited
to the case where all layers under GMPLS control are part of the same to the case where all layers under GMPLS control are part of the same
administrative domain. administrative domain.
Lastly, as noted in [MLN-REQ], it is expected that solution documents Lastly, as noted in [MLN-REQ], it is expected that solution documents
will include a full analysis of the security issues that any protocol will include a full analysis of the security issues that any protocol
extensions introduce. extensions introduce.
6. Acknowledgments 6. IANA Considerations
This informational document makes no requests for IANA action.
7. Acknowledgments
We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel
for their useful comments. for their useful comments.
Thanks also to Question 14 of Study Group 15 of the ITU-T for their Thanks also to Question 14 of Study Group 15 of the ITU-T for their
thoughtful review. thoughtful review.
7. References 8. References
7.1. Normative 8.1. Normative References
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF [RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label
Technology", BCP 79, RFC 3979, March 2005. Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[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 Extensions in Support of Generalized Multi-Protocol
Label Switching", draft-ietf-ccamp-gmpls-routing, Label Switching", RFC4202, October 2005.
RFC4202, October 2005.
[RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
7.2. Informative
[RSVP-CALL] Papadimitriou, D., Farrel, A., et. al., "Generalized 8.2. Informative References
MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
Calls", draft-ietf-ccamp-gmpls-rsvp-te-call, work in
progress.
[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE
Vigoureux, M., Brungard, D., "Requirements for GMPLS- extensions", RFC3473, January 2003.
based multi-region and multi-layer networks", draft-
ietf-ccamp-gmpls-mrn-reqs, work in progess.
[RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with [RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with
generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, generalized MPLS TE", RFC4206, October 2005.
RFC4206, October 2005.
[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic [RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based
Engineering Network", draft-ietf-ccamp-mpls-graceful- Architecture", RFC4655, August 2006.
shutdown, work in progress.
[RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802,
February 2007.
[RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in [RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
support of End-to-End Generalized Multi-Protocol Label support of End-to-End Generalized Multi-Protocol Label
Switching (GMPLS)-based Recovery", RFC4872, May 2007. Switching (GMPLS)-based Recovery", RFC4872, May 2007.
[VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network [RFC4974] Papadimitriou, D., Farrel, A., et. al., "Generalized
Topology Manager (VNTM) for PCE-based Inter-Layer MPLS MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
and GMPLS Traffic Engineering", draft-oki-pce-vntm-def, Calls", RFC 4974, August 2007.
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.
[RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions",
RFC3473, January 2003.
[RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic
Architecture", RFC4655, August 2006. Engineering Network", draft-ietf-ccamp-mpls-graceful-
shutdown, work in progress.
[RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802, [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L.,
February 2007. Vigoureux, M., Brungard, D., "Requirements for GMPLS-
based multi-region and multi-layer networks", draft-
ietf-ccamp-gmpls-mln-reqs, work in progess.
[MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS [MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS
Networks draft-fang-mpls-gmpls-security-framework, work Networks draft-fang-mpls-gmpls-security-framework, work
in progress. in progress.
8. Editors' Addresses: [PCE-INTER] Oki, E., Le Roux , J-L., and Farrel, A., "Framework for
PCE-Based Inter-Layer MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-layer-frwk, work in
progress.
9. Editors' Addresses:
Jean-Louis Le Roux 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-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel-Lucent Alcatel-Lucent
Francis Wellensplein 1, Francis Wellensplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Email: dimitri.papadimitriou@alcatel-lucent.be Email: dimitri.papadimitriou@alcatel-lucent.be
9. Contributors' Addresses: 10. 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
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
skipping to change at page 15, line 23 skipping to change at page 15, line 37
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp Email: shiomoto.kohei@lab.ntt.co.jp
M. Vigoureux M. Vigoureux
Alcatel-Lucent France Alcatel-Lucent France
Route de Villejust Route de Villejust
91620 Nozay 91620 Nozay
FRANCE FRANCE
Email: martin.vigoureux@alcatel-lucent.fr Email: martin.vigoureux@alcatel-lucent.fr
10. Intellectual Property Statement 11. 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
 End of changes. 37 change blocks. 
105 lines changed or deleted 98 lines changed or added

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