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/