draft-ietf-ccamp-gmpls-mln-reqs-11.txt   rfc5212.txt 
Network Working Group Kohei Shiomoto (NTT) Network Working Group K. Shiomoto
Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) Request for Comments: 5212 NTT
Intended Status: Informational Jean-Louis Le Roux (France Telecom) Category: Informational D. Papadimitriou
Created: May 28, 2008 Martin Vigoureux (Alcatel-Lucent) Alcatel-Lucent
Expires: November 28, 2008 Deborah Brungard (AT&T) JL. Le Roux
France Telecom
Requirements for GMPLS-Based Multi-Region and M. Vigoureux
Multi-Layer Networks (MRN/MLN) Alcatel-Lucent
D. Brungard
draft-ietf-ccamp-gmpls-mln-reqs-11.txt AT&T
Requirements for GMPLS-Based
Status of this Memo Multi-Region and Multi-Layer Networks (MRN/MLN)
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html
This Internet-Draft will expire in May 2008. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
Most of the initial efforts to utilize Generalized MPLS (GMPLS) Most of the initial efforts to utilize Generalized MPLS (GMPLS) have
have been related to environments hosting devices with a single been related to environments hosting devices with a single switching
switching capability. The complexity raised by the control of such capability. The complexity raised by the control of such data planes
data planes is similar to that seen in classical IP/MPLS networks. is similar to that seen in classical IP/MPLS networks. By extending
By extending MPLS to support multiple switching technologies, GMPLS MPLS to support multiple switching technologies, GMPLS provides a
provides a comprehensive framework for the control of a multi- comprehensive framework for the control of a multi-layered network of
layered network of either a single switching technology or multiple either a single switching technology or multiple switching
switching technologies. technologies.
In GMPLS, a switching technology domain defines a region, and a In GMPLS, a switching technology domain defines a region, and a
network of multiple switching types is referred to in this document network of multiple switching types is referred to in this document
as a Multi-Region Network (MRN). When referring in general to a as a multi-region network (MRN). When referring in general to a
layered network, which may consist of either a single or multiple layered network, which may consist of either single or multiple
regions, this document uses the term, Multi-Layer Network (MLN). regions, this document uses the term multi-layer network (MLN). This
This document defines a framework for GMPLS based multi-region / document defines a framework for GMPLS based multi-region / multi-
multi-layer networks and lists a set of functional requirements. layer networks and lists a set of functional requirements.
Table of Contents Table of Contents
1. Introduction.................................................3
1. Introduction ....................................................3
1.1. Scope......................................................4 1.1. Scope......................................................4
2. Conventions Used in this Document............................5 2. Conventions Used in This Document ...............................5
2.1. List of Acronyms...........................................5 2.1. List of Acronyms ...........................................6
3. Positioning..................................................6 3. Positioning .....................................................6
3.1. Data Plane Layers and Control Plane Regions................6 3.1. Data Plane Layers and Control Plane Regions................6
3.2. Service Layer Networks.....................................6 3.2. Service Layer Networks .....................................7
3.3. Vertical and Horizontal Interaction and Integration........7 3.3. Vertical and Horizontal Interaction and Integration ........8
3.4. Motivation.................................................8 3.4. Motivation .................................................9
4. Key Concepts of GMPLS-Based MLNs and MRNs....................9 4. Key Concepts of GMPLS-Based MLNs and MRNs ......................10
4.1. Interface Switching Capability.............................9 4.1. Interface Switching Capability ............................10
4.2. Multiple Interface Switching Capabilities.................10 4.2. Multiple Interface Switching Capabilities .................11
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes.11 4.2.1. Networks with Multi-Switching-Type-Capable
4.3. Integrated Traffic Engineering (TE) and Resource Control..11 Hybrid Nodes .......................................12
4.3.1. Triggered Signaling.....................................12 4.3. Integrated Traffic Engineering (TE) and Resource Control ..12
4.3.2. FA-LSPs.................................................12 4.3.1. Triggered Signaling ................................13
4.3.3. Virtual Network Topology (VNT)..........................13 4.3.2. FA-LSPs ............................................13
5. Requirements................................................14 4.3.3. Virtual Network Topology (VNT) .....................14
5.1. Handling Single-Switching and Multi-Switching-Type-Capable 5. Requirements ...................................................15
Nodes.....................................................14 5.1. Handling Single-Switching and
5.2. Advertisement of the Available Adjustment Resource........14 Multi-Switching-Type-Capable Nodes ........................15
5.3. Scalability...............................................15 5.2. Advertisement of the Available Adjustment Resources .......15
5.4. Stability.................................................16 5.3. Scalability ...............................................16
5.5. Disruption Minimization...................................16 5.4. Stability .................................................17
5.6. LSP Attribute Inheritance.................................16 5.5. Disruption Minimization ...................................17
5.7. Computing Paths With and Without Nested Signaling.........17 5.6. LSP Attribute Inheritance .................................17
5.8. LSP Resource Utilization..................................18 5.7. Computing Paths with and without Nested Signaling .........18
5.8.1. FA-LSP Release and Setup................................18 5.8. LSP Resource Utilization ..................................19
5.8.2. Virtual TE-Links........................................19 5.8.1. FA-LSP Release and Setup ...........................19
5.9. Verification of the LSPs..................................20 5.8.2. Virtual TE Links ...................................20
5.10. Management...............................................20 5.9. Verification of the LSPs ..................................21
6. Security Considerations.....................................23 5.10. Management ...............................................22
7. IANA Considerations.........................................23 6. Security Considerations ........................................24
8. Acknowledgements............................................23 7. Acknowledgements ...............................................24
9. References..................................................23 8. References .....................................................25
9.1. Normative Reference.......................................23 8.1. Normative References ......................................25
9.2. Informative References....................................24 8.2. Informative References ....................................25
10. Authors' Addresses.........................................25 9. Contributors' Addresses ........................................26
11. Contributors' Addresses....................................26
12. Intellectual Property Considerations.......................26
13. Full Copyright Statement...................................27
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 (Time-Division
wavelength switching, and fiber switching (see [RFC3945]). The Multiplexing) switching, wavelength switching, and fiber switching
Interface Switching Capability (ISC) concept is introduced for (see [RFC3945]). The Interface Switching Capability (ISC) concept is
these switching technologies and is designated as follows: PSC introduced for these switching technologies and is designated as
(packet switch capable), L2SC (Layer-2 switch capable), TDM (Time follows: PSC (packet switch capable), L2SC (Layer-2 switch capable),
Division Multiplex capable), LSC (lambda switch capable), and FSC TDM capable, LSC (lambda switch capable), and FSC (fiber switch
(fiber switch capable). capable).
The representation, in a GMPLS control plane, of a switching The representation, in a GMPLS control plane, of a switching
technology domain is referred to as a region [RFC4206]. A switching technology domain is referred to as a region [RFC4206]. A switching
type describes the ability of a node to forward data of a type describes the ability of a node to forward data of a particular
particular data plane technology, and uniquely identifies a network data plane technology, and uniquely identifies a network region. A
region. A layer describes a data plane switching granularity level layer describes a data plane switching granularity level (e.g., VC4,
(e.g., VC4, VC-12). A data plane layer is associated with a region VC-12). A data plane layer is associated with a region in the
in the control plane (e.g., VC4 is associated with TDM, MPLS is control plane (e.g., VC4 is associated with TDM, MPLS is associated
associated with PSC). However, more than one data plane layer can with PSC). However, more than one data plane layer can be associated
be associated with the same region (e.g., both VC4 and VC12 are with the same region (e.g., both VC4 and VC12 are associated with
associated with TDM). Thus, a control plane region, identified by TDM). Thus, a control plane region, identified by its switching type
its switching type value (e.g., TDM), can be sub-divided into value (e.g., TDM), can be sub-divided into smaller-granularity
smaller granularity component networks based on "data plane component networks based on "data plane switching layers". The
switching layers". The Interface Switching Capability Descriptor Interface Switching Capability Descriptor (ISCD) [RFC4202],
(ISCD) [RFC4202], identifying the interface switching capability identifying the interface switching capability (ISC), the encoding
(ISC), the encoding type, and the switching bandwidth granularity, type, and the switching bandwidth granularity, enables the
enables the characterization of the associated layers. characterization of the associated layers.
In this document, we define a Multi Layer Network (MLN) to be a In this document, we define a multi-layer network (MLN) to be a
Traffic Engineering (TE) domain comprising multiple data plane Traffic Engineering (TE) domain comprising multiple data plane
switching layers either of the same ISC (e.g., TDM) or different switching layers either of the same ISC (e.g., TDM) or different ISC
ISC (e.g., TDM and PSC) and controlled by a single GMPLS control (e.g., TDM and PSC) and controlled by a single GMPLS control plane
plane instance. We further define a particular case of MLNs. A instance. We further define a particular case of MLNs. A multi-
Multi Region Network (MRN) is defined as a TE domain supporting at region network (MRN) is defined as a TE domain supporting at least
least two different switching types (e.g., PSC and TDM), either two different switching types (e.g., PSC and TDM), either hosted on
hosted on the same device or on different ones, and under the the same device or on different ones, and under the control of a
control of a single GMPLS control plane instance. single GMPLS control plane instance.
MLNs can be further categorized according to the distribution of MLNs can be further categorized according to the distribution of the
the ISCs among the Label Switching Routers (LSRs): ISCs among the Label Switching Routers (LSRs):
- Each LSR may support just one ISC. - Each LSR may support just one ISC.
Such LSRs are known as single-switching-type-capable LSRs. Such LSRs are known as single-switching-type-capable LSRs. The MLN
The MLN may comprise a set of single-switching-type-capable LSRs may comprise a set of single-switching-type-capable LSRs some of
some of which support different ISCs. which support different ISCs.
- Each LSR may support more than one ISC at the same time. - Each LSR may support more than one ISC at the same time.
- Such LSRs are known as multi-switching-type-capable LSRs, and Such LSRs are known as multi-switching-type-capable LSRs, and can
can be further classified as either "simplex" or "hybrid" nodes be further classified as either "simplex" or "hybrid" nodes as
as defined in Section 4.2. defined in Section 4.2.
- The MLN may be constructed from any combination of single- - The MLN may be constructed from any combination of single-
switching-type-capable LSRs and multi-switching-type-capable switching-type-capable LSRs and multi-switching-type-capable LSRs.
LSRs.
Since GMPLS provides a comprehensive framework for the control of Since GMPLS provides a comprehensive framework for the control of
different switching capabilities, a single GMPLS instance may be different switching capabilities, a single GMPLS instance may be used
used to control the MLN/MRN. This enables rapid service to control the MLN/MRN. This enables rapid service provisioning and
provisioning and efficient traffic engineering across all switching efficient traffic engineering across all switching capabilities. In
capabilities. In such networks, TE Links are consolidated into a such networks, TE links are consolidated into a single Traffic
single Traffic Engineering Database (TED). Since this TED contains Engineering Database (TED). Since this TED contains the information
the information relative to all the different regions and layers relative to all the different regions and layers existing in the
existing in the network, a path across multiple regions or layers network, a path across multiple regions or layers can be computed
can be computed using this TED. Thus optimization of network using this TED. Thus, optimization of network resources can be
resources can be achieved across the whole MLN/MRN. achieved across the whole MLN/MRN.
Consider, for example, a MRN consisting of packet- switch capable Consider, for example, a MRN consisting of packet-switch-capable
routers and TDM cross-connects. Assume that a packet Label Switched routers and TDM cross-connects. Assume that a packet Label Switched
Path (LSP) is routed between source and destination packet-switch Path (LSP) is routed between source and destination packet-switch-
capable routers, and that the LSP can be routed across the PSC- capable routers, and that the LSP can be routed across the PSC region
region (i.e., utilizing only resources of the packet region (i.e., utilizing only resources of the packet region topology). If
topology). If the performance objective for the packet LSP is not the performance objective for the packet LSP is not satisfied, new TE
satisfied, new TE links may be created between the packet-switch links may be created between the packet-switch-capable routers across
capable routers across the TDM-region (for example, VC-12 links) the TDM-region (for example, VC-12 links) and the LSP can be routed
and the LSP can be routed over those TE links. Furthermore, even if over those TE links. Furthermore, even if the LSP can be
the LSP can be successfully established across the PSC-region, TDM successfully established across the PSC-region, TDM hierarchical LSPs
hierarchical LSPs across the TDM region between the packet-switch (across the TDM region between the packet-switch capable routers) may
capable routers may be established and used if doing so is be established and used if doing so is necessary to meet the
necessary to meet the operator's objectives for network resources operator's objectives for network resource availability (e.g., link
availability (e.g., link bandwidth). The same considerations hold bandwidth). The same considerations hold when VC4 LSPs are
when VC4 LSPs are provisioned to provide extra flexibility for the provisioned to provide extra flexibility for the VC12 and/or VC11
VC12 and/or VC11 layers in an MLN. layers in an MLN.
Sections 3 and 4 of this document provide further background Sections 3 and 4 of this document provide further background
information of the concepts and motivation behind multi-region and information of the concepts and motivation behind multi-region and
multi-layer networks. Section 5 presents detailed requirements for multi-layer networks. Section 5 presents detailed requirements for
protocols used to implement such networks. protocols used to implement such networks.
1.1.Scope 1.1.Scope
Early sections of this document describe the motivations and Early sections of this document describe the motivations and
reasoning that require the development and deployment of MRN/MLN. reasoning that require the development and deployment of MRN/MLN.
Later sections of this document set out the required features that Later sections of this document set out the required features that
the GMPLS control plane must offer to support MRN/MLN. There is no the GMPLS control plane must offer to support MRN/MLN. There is no
intention to specify solution- specific and/or protocol elements in intention to specify solution- specific and/or protocol elements in
this document. The applicability of existing GMPLS protocols and this document. The applicability of existing GMPLS protocols and any
any protocol extensions to the MRN/MLN is addressed in separate protocol extensions to the MRN/MLN is addressed in separate documents
documents [MRN-EVAL]. [MRN-EVAL].
This document covers the elements of a single GMPLS control plane This document covers the elements of a single GMPLS control plane
instance controlling multiple layers within a given TE domain. A instance controlling multiple layers within a given TE domain. A
control plane instance can serve one, two or more layers. Other control plane instance can serve one, two, or more layers. Other
possible approaches such as having multiple control plane instances possible approaches such as having multiple control plane instances
serving disjoint sets of layers are outside the scope of this serving disjoint sets of layers are outside the scope of this
document. It is most probable that such a MLN or MRN would be document. It is most probable that such a MLN or MRN would be
operated by a single Service Provider, but this document does not operated by a single service provider, but this document does not
exclude the possibility of two layers (or regions) being under exclude the possibility of two layers (or regions) being under
different administrative control (for example, by different Service different administrative control (for example, by different Service
Providers that share a single control plane instance) where the Providers that share a single control plane instance) where the
administrative domains are prepared to share a limited amount of administrative domains are prepared to share a limited amount of
information. information.
For such TE domain to interoperate with edge nodes/domains For such a TE domain to interoperate with edge nodes/domains
supporting non-GMPLS interfaces (such as those defined by other supporting non-GMPLS interfaces (such as those defined by other
SDOs), an interworking function may be needed. Location and standards development organizations (SDOs)), an interworking function
specification of this function are outside the scope of this may be needed. Location and specification of this function are
document (because interworking aspects are strictly under the outside the scope of this document (because interworking aspects are
responsibility of the interworking function). strictly under the responsibility of the interworking function).
This document assumes that the interconnection of adjacent MRN/MLN This document assumes that the interconnection of adjacent MRN/MLN TE
TE domains makes use of [RFC4726] when their edges also support domains makes use of [RFC4726] when their edges also support inter-
inter- domain GMPLS RSVP-TE extensions. domain GMPLS RSVP-TE extensions.
2. Conventions Used in this Document 2. Conventions Used in This Document
Although this is not a protocol specification, the key words "MUST", Although this is not a protocol specification, the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in this "RECOMMENDED", "MAY", and "OPTIONAL" are used in this document to
document to highlight requirements, and are to be interpreted as highlight requirements, and are to be interpreted as described in RFC
described in RFC 2119 [RFC2119]. 2119 [RFC2119].
In the context of this document, an end-to-end LSP is defined as an
LSP that starts in some client layer, ends in the same layer, and may
cross one or more lower layers. In terms of switching capabilities,
this means that if the outgoing interface on the head-end LSR has
interface switching capability X, then the incoming interface on the
tail-end LSR also has switching capability X. Further, for any
interface traversed by the LSP at any intermediate LSR, the switching
capability of that interface, Y, is such that Y >= X.
2.1.List of Acronyms 2.1.List of Acronyms
ERO: Explicit Route Object ERO: Explicit Route Object
FA: Forwarding Adjacency FA: Forwarding Adjacency
FA-LSP: Forwarding Adjacency Label Switched Path FA-LSP: Forwarding Adjacency Label Switched Path
FSC: Fiber Switching Capable FSC: Fiber Switching Capable
ISC: Interface Switching Capability ISC: Interface Switching Capability
ISCD: Interface Switching Capability Descriptor ISCD: Interface Switching Capability Descriptor
L2SC: Layer-2 Switching Capable L2SC: Layer-2 Switching Capable
LSC: Lambda Switching Capable LSC: Lambda Switching Capable
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
MLN: Multi-Layer Network MLN: Multi-Layer Network
MRN: Multi-Region Network MRN: Multi-Region Network
PSC: Packet Switching Capable PSC: Packet Switching Capable
SRLG: Shared Risk Ling Group SRLG: Shared Risk Link Group
TDM: Time-Division Switch Capable TDM: Time-Division Multiplexing
TE: Traffic Engineering TE: Traffic Engineering
TED: Traffic Engineering Database TED: Traffic Engineering Database
VNT: Virtual Network Topology VNT: Virtual Network Topology
3. Positioning 3. Positioning
A multi-region network (MRN) is always a multi-layer network (MLN) A multi-region network (MRN) is always a multi-layer network (MLN)
since the network devices on region boundaries bring together since the network devices on region boundaries bring together
different ISCs. A MLN, however, is not necessarily a MRN since different ISCs. A MLN, however, is not necessarily a MRN since
multiple layers could be fully contained within a single region. multiple layers could be fully contained within a single region. For
For example, VC12, VC4, and VC4-4c are different layers of the TDM example, VC12, VC4, and VC4-4c are different layers of the TDM
region. region.
3.1. Data Plane Layers and Control Plane Regions 3.1. Data Plane Layers and Control Plane Regions
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 terminating and/or switching data traffic of a particular format
[RFC4397]. These resources can be used for establishing LSPs for [RFC4397]. These resources can be used for establishing LSPs for
traffic delivery. For example, VC-11 and VC4-64c represent two traffic delivery. For example, VC-11 and VC4-64c represent two
different layers. different layers.
From the control plane viewpoint, an LSP region is defined as a set From the control plane viewpoint, an LSP region is defined as a set
of one or more data plane layers that share the same type of of one or more data plane layers that share the same type of
switching technology, that is, the same switching type. For example, switching technology, that is, the same switching type. For example,
VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. The
The regions that are currently defined are: PSC, L2SC, TDM, LSC, regions that are currently defined are: PSC, L2SC, TDM, LSC, and FSC.
and FSC. Hence, an LSP region is a technology domain (identified by Hence, an LSP region is a technology domain (identified by the ISC
the ISC type) for which data plane resources (i.e., data links) are type) for which data plane resources (i.e., data links) are
represented into the control plane as an aggregate of TE represented into the control plane as an aggregate of TE information
information associated with a set of links (i.e., TE links). For associated with a set of links (i.e., TE links). For example, VC-11
example VC-11 and VC4-64c capable TE links are part of the same TDM and VC4-64c capable TE links are part of the same TDM region.
region. Multiple layers can thus exist in a single region network. Multiple layers can thus exist in a single region network.
Note also that the region may produce a distinction within the Note also that the region may produce a distinction within the
control plane. Layers of the same region share the same switching control plane. Layers of the same region share the same switching
technology and, therefore, use the same set of technology-specific technology and, therefore, use the same set of technology-specific
signaling objects and technology-specific value setting of TE link signaling objects and technology-specific value setting of TE link
attributes within the control plane, but layers from different attributes within the control plane, but layers from different
regions may use different technology-specific objects and TE regions may use different technology-specific objects and TE
attribute values. This means that it may not be possible to simply attribute values. This means that it may not be possible to simply
forward the signaling message between LSR hosting different forward the signaling message between LSRs that host different
switching technologies because change in some of the signaling switching technologies. This is due to changes in some of the
objects (for example, the traffic parameters) when crossing a signaling objects (for example, the traffic parameters) when crossing
region boundary even if a single control plane instance is used to a region boundary even if a single control plane instance is used to
manage the whole MRN. We may solve this issue by using triggered manage the whole MRN. We may solve this issue by using triggered
signaling (see Section 4.3.1). signaling (see Section 4.3.1).
3.2. Service Layer Networks 3.2. Service Layer Networks
A service provider's network may be divided into different service A service provider's network may be divided into different service
layers. The customer's network is considered from the provider's layers. The customer's network is considered from the provider's
perspective as the highest service layer. It interfaces to the perspective as the highest service layer. It interfaces to the
highest service layer of the service provider's network. highest service layer of the service provider's network.
Connectivity across the highest service layer of the service Connectivity across the highest service layer of the service
provider's network may be provided with support from successively provider's network may be provided with support from successively
lower service layers. Service layers are realized via a hierarchy lower service layers. Service layers are realized via a hierarchy of
of network layers located generally in several regions and commonly network layers located generally in several regions and commonly
arranged according to the switching capabilities of network devices. arranged according to the switching capabilities of network devices.
For instance some customers purchase Layer 1 (i.e., transport) For instance, some customers purchase Layer-1 (i.e., transport)
services from the service provider, some Layer 2 (e.g., ATM), while services from the service provider, some Layer 2 (e.g., ATM), while
others purchase Layer 3 (IP/MPLS) services. The service provider others purchase Layer-3 (IP/MPLS) services. The service provider
realizes the services by a stack of network layers located within realizes the services by a stack of network layers located within one
one or more network regions. The network layers are commonly or more network regions. The network layers are commonly arranged
arranged according to the switching capabilities of the devices in according to the switching capabilities of the devices in the
the networks. Thus, a customer network may be provided on top of networks. Thus, a customer network may be provided on top of the
the GMPLS-based multi-region/multi-layer network. For example, a GMPLS-based multi-region/multi-layer network. For example, a Layer-1
Layer 1 service (realized via the network layers of TDM, and/or LSC, service (realized via the network layers of TDM, and/or LSC, and/or
and/or FSC regions) may support a Layer 2 network (realized via ATM FSC regions) may support a Layer-2 network (realized via ATM Virtual
VP/VC) which may itself support a Layer 3 network (IP/MPLS region). Path / Virtual Circuit (VP/VC)), which may itself support a Layer-3
The supported data plane relationship is a data plane client-server network (IP/MPLS region). The supported data plane relationship is a
relationship where the lower layer provides a service for the data plane client-server relationship where the lower layer provides
higher layer using the data links realized in the lower layer. a service for the higher layer using the data links realized in the
lower layer.
Services provided by a GMPLS-based multi-region/multi-layer network Services provided by a GMPLS-based multi-region/multi-layer network
are referred to as "Multi-region/Multi-layer network services". For are referred to as "multi-region/multi-layer network services". For
example, legacy IP and IP/MPLS networks can be supported on top of example, legacy IP and IP/MPLS networks can be supported on top of
multi-region/multi-layer networks. It has to be emphasized that multi-region/multi-layer networks. It has to be emphasized that
delivery of such diverse services is a strong motivator for the delivery of such diverse services is a strong motivator for the
deployment of multi-region/multi-layer networks. deployment of multi-region/multi-layer networks.
A customer network may be provided on top of a server GMPLS-based A customer network may be provided on top of a server GMPLS-based
MRN/MLN which is operated by a service provider. For example, a MRN/MLN which is operated by a service provider. For example, a pure
pure IP and/or an IP/MPLS network can be provided on top of GMPLS- IP and/or an IP/MPLS network can be provided on top of GMPLS-based
based packet over optical networks [RFC5146]. The relationship packet-over-optical networks [RFC5146]. The relationship between the
between the networks is a client/server relationship and, such networks is a client/server relationship and, such services are
services are referred to as "MRN/MLN services". In this case, the referred to as "MRN/MLN services". In this case, the customer
customer network may form part of the MRN/MLN, or may be partially network may form part of the MRN/MLN or may be partially separated,
separated, for example to maintain separate routing information but for example, to maintain separate routing information but retain
retain common signaling. common signaling.
3.3. Vertical and Horizontal Interaction and Integration 3.3. Vertical and Horizontal Interaction and Integration
Vertical interaction is defined as the collaborative mechanisms Vertical interaction is defined as the collaborative mechanisms
within a network element that is capable of supporting more than within a network element that is capable of supporting more than one
one layer or region and of realizing the client/server layer or region and of realizing the client/server relationships
relationships between the layers or regions. Protocol exchanges between the layers or regions. Protocol exchanges between two
between two network controllers managing different regions or network controllers managing different regions or layers are also a
layers are also a vertical interaction. Integration of these vertical interaction. Integration of these interactions as part of
interactions as part of the control plane is referred to as the control plane is referred to as vertical integration. Thus, this
vertical integration. Thus, this refers to the collaborative refers to the collaborative mechanisms within a single control plane
mechanisms within a single control plane instance driving multiple instance driving multiple network layers that are part of the same
network layers part of the same region or not. Such a concept is region or not. Such a concept is useful in order to construct a
useful in order to construct a framework that facilitates efficient framework that facilitates efficient network resource usage and rapid
network resource usage and rapid service provisioning in carrier service provisioning in carrier networks that are based on multiple
networks that are based on multiple layers, switching technologies, layers, switching technologies, or ISCs.
or ISCs.
Horizontal interaction is defined as the protocol exchange between Horizontal interaction is defined as the protocol exchange between
network controllers that manage transport nodes within a given network controllers that manage transport nodes within a given layer
layer or region. For instance, the control plane interaction or region. For instance, the control plane interaction between two
between two TDM network elements switching at OC-48 is an example TDM network elements switching at OC-48 is an example of horizontal
of horizontal interaction. GMPLS protocol operations handle interaction. GMPLS protocol operations handle horizontal
horizontal interactions within the same routing area. The case interactions within the same routing area. The case where the
where the interaction takes place across a domain boundary, such as interaction takes place across a domain boundary, such as between two
between two routing areas within the same network layer, is routing areas within the same network layer, is evaluated as part of
evaluated as part of the inter- domain work [RFC4726], and is the inter-domain work [RFC4726], and is referred to as horizontal
referred to as horizontal integration. Thus, horizontal integration integration. Thus, horizontal integration refers to the
refers to the collaborative mechanisms between network partitions collaborative mechanisms between network partitions and/or
and/or administrative divisions such as routing areas or autonomous administrative divisions such as routing areas or autonomous systems.
systems.
This distinction needs further clarification when administrative This distinction needs further clarification when administrative
domains match layer/region boundaries. Horizontal interaction is domains match layer/region boundaries. Horizontal interaction is
extended to cover such cases. For example, the collaborative extended to cover such cases. For example, the collaborative
mechanisms in place between two lambda switching capable areas mechanisms in place between two LSC areas relate to horizontal
relate to horizontal integration. On the other hand, the integration. On the other hand, the collaborative mechanisms in
collaborative mechanisms in place between a packet switching place between a PSC (e.g., IP/MPLS) domain and a separate TDM capable
capable (e.g., IP/MPLS) domain and a separate time division (e.g., VC4 Synchronous Digital Hierarchy (SDH)) domain over which it
switching capable (e.g., VC4 SDH) domain over which it operates are operates are part of the horizontal integration, while it can also be
part of the horizontal integration while it can also be seen as a seen as a first step towards vertical integration.
first step towards vertical integration.
3.4.Motivation 3.4.Motivation
The applicability of GMPLS to multiple switching technologies The applicability of GMPLS to multiple switching technologies
provides a unified control and management approach for both LSP provides a unified control and management approach for both LSP
provisioning and recovery. Indeed, one of the main motivations for provisioning and recovery. Indeed, one of the main motivations for
unifying the capabilities and operations of the GMPLS control plane unifying the capabilities and operations of the GMPLS control plane
is the desire to support multi-LSP-region [RFC4206] routing and is the desire to support multi-LSP-region [RFC4206] routing and TE
Traffic Engineering (TE) capabilities. For instance, this enables capabilities. For instance, this enables effective network resource
effective network resource utilization of both the Packet/Layer2 utilization of both the Packet/Layer2 LSP regions and the TDM or
LSP regions and the Time Division Multiplexing (TDM) or Lambda LSP Lambda LSP regions in high-capacity networks.
regions in high capacity networks.
The rationales for GMPLS controlled multi-layer/multi-region The rationales for GMPLS-controlled multi-layer/multi-region networks
networks are summarized below: are summarized below:
- The maintenance of multiple instances of the control plane on - The maintenance of multiple instances of the control plane on
devices hosting more than one switching capability not only devices hosting more than one switching capability not only
increases the complexity of their interactions but also increases increases the complexity of the interactions between control plane
the total amount of processing individual instances would handle. instances, but also increases the total amount of processing each
individual control plane instance must handle.
- The unification of the addressing spaces helps in avoiding - The unification of the addressing spaces helps in avoiding multiple
multiple identifiers for the same object (a link, for instance, identifiers for the same object (a link, for instance, or more
or more generally, any network resource). On the other hand such generally, any network resource). On the other hand such
aggregation does not impact the separation between the control aggregation does not impact the separation between the control
plane and the data plane. plane and the data plane.
- By maintaining a single routing protocol instance and a single TE - By maintaining a single routing protocol instance and a single TE
database per LSR, a unified control plane model removes the database per LSR, a unified control plane model removes the
requirement to maintain a dedicated routing topology per layer requirement to maintain a dedicated routing topology per layer and
and therefore does not mandate a full mesh of routing adjacencies therefore does not mandate a full mesh of routing adjacencies as is
as is the case with overlaid control planes. the case with overlaid control planes.
- The collaboration between technology layers where the control - The collaboration between technology layers where the control
channel is associated with the data channel (e.g. packet/framed channel is associated with the data channel (e.g., packet/framed
data planes) and technology layers where the control channel is data planes) and technology layers where the control channel is not
not directly associated with the data channel (SONET/SDH, G.709, directly associated with the data channel (SONET/SDH, G.709, etc.)
etc.) is facilitated by the capability within GMPLS to associate is facilitated by the capability within GMPLS to associate in-band
in-band control plane signaling to the IP terminating interfaces control plane signaling to the IP terminating interfaces of the
of the control plane. control plane.
- Resource management and policies to be applied at the edges of - Resource management and policies to be applied at the edges of such
such a MRN/MLN is made more simple (fewer control to management an MRN/MLN are made more simple (fewer control-to-management
interactions) and more scalable (through the use of aggregated interactions) and more scalable (through the use of aggregated
information). information).
- Multi-region/multi-layer traffic engineering is facilitated as - Multi-region/multi-layer traffic engineering is facilitated as TE
TE-links from distinct regions/layers are stored within the same links from distinct regions/layers are stored within the same TE
TE Database. Database.
4. Key Concepts of GMPLS-Based MLNs and MRNs 4. Key Concepts of GMPLS-Based MLNs and MRNs
A network comprising transport nodes with multiple data plane A network comprising transport nodes with multiple data plane layers
layers of either the same ISC or different ISCs, controlled by a of either the same ISC or different ISCs, controlled by a single
single GMPLS control plane instance, is called a Multi-Layer GMPLS control plane instance, is called a multi-layer network (MLN).
Network (MLN). A sub-set of MLNs consists of networks supporting A subset of MLNs consists of networks supporting LSPs of different
LSPs of different switching technologies (ISCs). A network switching technologies (ISCs). A network supporting more than one
supporting more than one switching technology is called a Multi- switching technology is called a multi-region network (MRN).
Region Network (MRN).
4.1. Interface Switching Capability 4.1. Interface Switching Capability
The Interface Switching Capability (ISC) is introduced in GMPLS to The Interface Switching Capability (ISC) is introduced in GMPLS to
support various kinds of switching technology in a unified way support various kinds of switching technology in a unified way
[RFC4202]. An ISC is identified via a switching type. [RFC4202]. An ISC is identified via a switching type.
A switching type (also referred to as the switching capability A switching type (also referred to as the switching capability type)
type) describes the ability of a node to forward data of a describes the ability of a node to forward data of a particular data
particular data plane technology, and uniquely identifies a network plane technology, and uniquely identifies a network region. The
region. The following ISC types (and, hence, regions) are defined: following ISC types (and, hence, regions) are defined: PSC, L2SC,
PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more TDM capable, LSC, and FSC. Each end of a data link (more precisely,
precisely, each interface connecting a data link to a node) in a each interface connecting a data link to a node) in a GMPLS network
GMPLS network is associated with an ISC. is associated with an ISC.
The ISC value is advertised as a part of the Interface Switching The ISC value is advertised as a part of the Interface Switching
Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end
associated with a particular link interface [RFC4202]. Apart from associated with a particular link interface [RFC4202]. Apart from
the ISC, the ISCD contains information including the encoding type, the ISC, the ISCD contains information including the encoding type,
the bandwidth granularity, and the unreserved bandwidth on each of the bandwidth granularity, and the unreserved bandwidth on each of
eight priorities at which LSPs can be established. The ISCD does eight priorities at which LSPs can be established. The ISCD does not
not "identify" network layers, it uniquely characterizes "identify" network layers, it uniquely characterizes information
information associated to one or more network layers. associated to one or more network layers.
TE link end advertisements may contain multiple ISCDs. This can be TE link end advertisements may contain multiple ISCDs. This can be
interpreted as advertising a multi-layer (or multi-switching- interpreted as advertising a multi-layer (or multi-switching-
capable) TE link end. That is, the TE link end (and therefore the capable) TE link end. That is, the TE link end (and therefore the TE
TE link) is present in multiple layers. link) is present in multiple layers.
4.2. Multiple Interface Switching Capabilities 4.2. Multiple Interface Switching Capabilities
In an MLN, network elements may be single-switching-type-capable or In an MLN, network elements may be single-switching-type-capable or
multi-switching-type-capable nodes. Single-switching-type-capable multi-switching-type-capable nodes. Single-switching-type-capable
nodes advertise the same ISC value as part of their ISCD sub-TLV(s) nodes advertise the same ISC value as part of their ISCD sub-TLV(s)
to describe the termination capabilities of each of their TE to describe the termination capabilities of each of their TE link(s).
Link(s). This case is described in [RFC4202]. This case is described in [RFC4202].
Multi-switching-type-capable LSRs are classified as "simplex" or Multi-switching-type-capable LSRs are classified as "simplex" or
"hybrid" nodes. Simplex and hybrid nodes are categorized according "hybrid" nodes. Simplex and hybrid nodes are categorized according
to the way they advertise these multiple ISCs: to the way they advertise these multiple ISCs:
- A simplex node can terminate data links with different switching - A simplex node can terminate data links with different switching
capabilities where each data link is connected to the node by a capabilities where each data link is connected to the node by a
separate link interface. So, it advertises several TE Links each separate link interface. So, it advertises several TE links each
with a single ISC value carried in its ISCD sub-TLV (following with a single ISC value carried in its ISCD sub-TLV (following the
the rules defined in [RFC4206]). For example, an LSR with PSC and rules defined in [RFC4206]). An example is an LSR with PSC and TDM
TDM links each of which is connected to the LSR via a separate links each of which is connected to the LSR via a separate
interface. interface.
- A hybrid node can terminate data links with different switching - A hybrid node can terminate data links with different switching
capabilities where the data links are connected to the node by capabilities where the data links are connected to the node by the
the same interface. So, it advertises a single TE Link same interface. So, it advertises a single TE link containing more
containing more than one ISCD each with a different ISC value. than one ISCD each with a different ISC value. For example, a node
For example, a node may terminate PSC and TDM data links and may terminate PSC and TDM data links and interconnect those
interconnect those external data links via internal links. The external data links via internal links. The external interfaces
external interfaces connected to the node have both PSC and TDM connected to the node have both PSC and TDM capabilities.
capabilities.
Additionally, TE link advertisements issued by a simplex or a Additionally, TE link advertisements issued by a simplex or a hybrid
hybrid node may need to provide information about the node's node may need to provide information about the node's internal
internal adjustment capacity between the switching technologies adjustment capabilities between the switching technologies supported.
supported. The term "adjustment" capacity refers to the property of The term "adjustment" refers to the property of a hybrid node to
an hybrid node to interconnect different switching capabilities it interconnect the different switching capabilities that it provides
provides through its external interfaces.. This information allows through its external interfaces. The information about the
path computation to select an end- to-end multi-layer or multi- adjustment capabilities of the nodes in the network allows the path
region path that includes links of different switching capabilities computation process to select an end-to-end multi-layer or multi-
that are joined by LSRs that can adapt the signal between the links. region path that includes links with different switching capabilities
joined by LSRs that can adapt (i.e., adjust) the signal between the
links.
4.2.1.Networks with Multi-Switching-Type-Capable Hybrid Nodes 4.2.1.Networks with Multi-Switching-Type-Capable Hybrid Nodes
This type of network contains at least one hybrid node, zero or This type of network contains at least one hybrid node, zero or more
more simplex nodes, and a set of single-switching-type-capable simplex nodes, and a set of single-switching-type-capable nodes.
nodes.
Figure 1 shows an example hybrid node. The hybrid node has two Figure 1 shows an example hybrid node. The hybrid node has two
switching elements (matrices), which support, for instance, TDM and switching elements (matrices), which support, for instance, TDM and
PSC switching respectively. The node terminates a PSC and a TDM PSC switching, respectively. The node terminates a PSC and a TDM
link (Link1 and Link2 respectively). It also has an internal link link (Link1 and Link2, respectively). It also has an internal link
connecting the two switching elements. connecting 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, say, way that it is possible to terminate some of the resources of, say,
Link2 and provide adjustment for PSC traffic received/sent over the Link2 and provide adjustment for PSC traffic received/sent over the
PSC interface (#b). This situation is modeled in GMPLS by PSC interface (#b). This situation is modeled in GMPLS by connecting
connecting the local end of Link2 to the TDM switching element via the local end of Link2 to the TDM switching element via an additional
an additional interface realizing the termination/adjustment interface realizing the termination/adjustment function. There are
function. There are two possible ways to set up PSC LSPs through two possible ways to set up PSC LSPs through the hybrid node.
the hybrid node. Available resource advertisement (i.e., Unreserved Available resource advertisement (i.e., Unreserved and Min/Max LSP
and Min/Max LSP Bandwidth) should cover both of these methods. Bandwidth) should cover both of these methods.
............................. .............................
: Network element : : Network element :
: -------- : : -------- :
: | PSC | : : | PSC | :
Link1 -------------<->--|#a | : Link1 -------------<->--|#a | :
: | | : : | | :
: +--<->---|#b | : : +--<->---|#b | :
: | -------- : : | -------- :
: | ---------- : : | ---------- :
TDM : +--<->--|#c TDM | : TDM : +--<->--|#c TDM | :
+PSC : | | : +PSC : | | :
Link2 ------------<->--|#d | : Link2 ------------<->--|#d | :
: ---------- : : ---------- :
:............................ :............................
Figure 1. Hybrid node. Figure 1. Hybrid node.
4.3. Integrated Traffic Engineering (TE) and Resource Control 4.3. Integrated Traffic Engineering (TE) and Resource Control
In GMPLS-based multi-region/multi-layer networks, TE Links may be In GMPLS-based multi-region/multi-layer networks, TE links may be
consolidated into a single Traffic Engineering Database (TED) for consolidated into a single Traffic Engineering Database (TED) for use
use by the single control plane instance. Since this TED contains by the single control plane instance. Since this TED contains the
the information relative to all the layers of all regions in the information relative to all the layers of all regions in the network,
network, a path across multiple layers (possibly crossing multiple a path across multiple layers (possibly crossing multiple regions)
regions) can be computed using the information in this TED. Thus, can be computed using the information in this TED. Thus,
optimization of network resources across the multiple layers of the optimization of network resources across the multiple layers of the
same region and across multiple regions can be achieved. same region and across multiple regions can be achieved.
These concepts allow for the operation of one network layer over These concepts allow for the operation of one network layer over the
the topology (that is, TE links) provided by other network layers topology (that is, TE links) provided by other network layers (for
(for example, the use of a lower layer LSC LSP carrying PSC LSPs). example, the use of a lower-layer LSC LSP carrying PSC LSPs). In
In turn, a greater degree of control and inter-working can be turn, a greater degree of control and interworking can be achieved,
achieved, including (but not limited too): including (but not limited to):
- Dynamic establishment of Forwarding Adjacency (FA) LSPs - Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206]
[RFC4206] (see Sections 4.3.2 and 4.3.3). (see Sections 4.3.2 and 4.3.3).
- Provisioning of end-to-end LSPs with dynamic triggering of FA - Provisioning of end-to-end LSPs with dynamic triggering of FA LSPs.
LSPs.
Note that in a multi-layer/multi-region network that includes Note that in a multi-layer/multi-region network that includes multi-
multi- switching-type-capable nodes, an explicit route used to switching-type-capable nodes, an explicit route used to establish an
establish an end-to-end LSP can specify nodes that belong to end-to-end LSP can specify nodes that belong to different layers or
different layers or regions. In this case, a mechanism to control regions. In this case, a mechanism to control the dynamic creation
the dynamic creation of FA-LSPs may be required (see Sections 4.3.2 of FA-LSPs may be required (see Sections 4.3.2 and 4.3.3).
and 4.3.3).
There is a full spectrum of options to control how FA-LSPs are There is a full spectrum of options to control how FA-LSPs are
dynamically established. The process can be subject to the control dynamically established. The process can be subject to the control
of a policy, which may be set by a management component, and which of a policy, which may be set by a management component and which may
may require that the management plane is consulted at the time that require that the management plane is consulted at the time that the
the FA-LSP is established. Alternatively, the FA-LSP can be FA-LSP is established. Alternatively, the FA-LSP can be established
established at the request of the control plane without any at the request of the control plane without any management control.
management control.
4.3.1. Triggered Signaling 4.3.1. Triggered Signaling
When an LSP crosses the boundary from an upper to a lower layer, it When an LSP crosses the boundary from an upper to a lower layer, it
may be nested into a lower layer FA-LSP that crosses the lower may be nested into a lower-layer FA-LSP that crosses the lower layer.
layer. From a signaling perspective, there are two alternatives to From a signaling perspective, there are two alternatives to establish
establish the lower layer FA-LSP: static (pre-provisioned) and the lower-layer FA-LSP: static (pre-provisioned) and dynamic
dynamic (triggered). A pre-provisioned FA-LSP may be initiated (triggered). A pre-provisioned FA-LSP may be initiated either by the
either by the operator or automatically using features like TE operator or automatically using features like TE auto-mesh [RFC4972].
auto-mesh [RFC4972]. If such a lower layer LSP does not already If such a lower-layer LSP does not already exist, the LSP may be
exist, the LSP may be established dynamically. Such a mechanism is established dynamically. Such a mechanism is referred to as
referred to as "triggered signaling". "triggered signaling".
4.3.2. FA-LSPs 4.3.2. FA-LSPs
Once an LSP is created across a layer from one layer border node to Once an LSP is created across a layer from one layer border node to
another, it can be used as a data link in an upper layer. another, it can be used as a data link in an upper layer.
Furthermore, it can be advertised as a TE-link, allowing other Furthermore, it can be advertised as a TE link, allowing other nodes
nodes to consider the LSP as a TE link for their path computation to consider the LSP as a TE link for their path computation
[RFC4206]. An LSP created either statically or dynamically by one [RFC4206]. An LSP created either statically or dynamically by one
instance of the control plane and advertised as a TE link into the instance of the control plane and advertised as a TE link into the
same instance of the control plane is called a Forwarding Adjacency same instance of the control plane is called a Forwarding Adjacency
LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE
link is called a Forwarding Adjacency (FA). An FA has the special link is called a Forwarding Adjacency (FA). An FA has the special
characteristic of not requiring a routing adjacency (peering) characteristic of not requiring a routing adjacency (peering) between
between its end points yet still guaranteeing control plane its end points yet still guaranteeing control plane connectivity
connectivity between the FA-LSP end points based on a signaling between the FA-LSP end points based on a signaling adjacency. An FA
adjacency. An FA is a useful and powerful tool for improving the is a useful and powerful tool for improving the scalability of
scalability of GMPLS Traffic Engineering (TE) capable networks GMPLS-TE capable networks since multiple higher-layer LSPs may be
since multiple higher layer LSPs may be nested (aggregated) over a nested (aggregated) over a single FA-LSP.
single FA-LSP.
The aggregation of LSPs enables the creation of a vertical (nested) The aggregation of LSPs enables the creation of a vertical (nested)
LSP Hierarchy. A set of FA-LSPs across or within a lower layer can LSP hierarchy. A set of FA-LSPs across or within a lower layer can
be used during path selection by a higher layer LSP. Likewise, the be used during path selection by a higher-layer LSP. Likewise, the
higher layer LSPs may be carried over dynamic data links realized higher-layer LSPs may be carried over dynamic data links realized via
via LSPs (just as they are carried over any "regular" static data LSPs (just as they are carried over any "regular" static data links).
links). This process requires the nesting of LSPs through a This process requires the nesting of LSPs through a hierarchical
hierarchical process [RFC4206]. The TED contains a set of LSP process [RFC4206]. The TED contains a set of LSP advertisements from
advertisements from different layers that are identified by the different layers that are identified by the ISCD contained within the
ISCD contained within the TE link advertisement associated with the TE link advertisement associated with the LSP [RFC4202].
LSP [RFC4202].
If a lower layer LSP is not advertised as an FA, it can still be If a lower-layer LSP is not advertised as an FA, it can still be used
used to carry higher layer LSPs across the lower layer. For example, to carry higher-layer LSPs across the lower layer. For example, if
if the LSP is set up using triggered signaling, it will be used to the LSP is set up using triggered signaling, it will be used to carry
carry the higher layer LSP that caused the trigger. Further, the the higher-layer LSP that caused the trigger. Further, the lower
lower layer remains available for use by other higher layer LSPs layer remains available for use by other higher-layer LSPs arriving
arriving at the boundary. at the boundary.
Under some circumstances it may be useful to control the Under some circumstances, it may be useful to control the
advertisement of LSPs as FAs during the signaling establishment of advertisement of LSPs as FAs during the signaling establishment of
the LSPs [DYN-HIER]. the LSPs [DYN-HIER].
4.3.3. Virtual Network Topology (VNT) 4.3.3. Virtual Network Topology (VNT)
A set of one or more of lower-layer LSPs provides information for A set of one or more lower-layer LSPs provides information for
efficient path handling in upper-layer(s) of the MLN, or, in other efficient path handling in upper layer(s) of the MLN, or, in other
words, provides a virtual network topology (VNT) to the upper- words, provides a virtual network topology (VNT) to the upper layers.
layers. For instance, a set of LSPs, each of which is supported by For instance, a set of LSPs, each of which is supported by an LSC
an LSC LSP, provides a virtual network topology to the layers of a LSP, provides a VNT to the layers of a PSC region, assuming that the
PSC region, assuming that the PSC region is connected to the LSC PSC region is connected to the LSC region. Note that a single
region. Note that a single lower-layer LSP is a special case of the lower-layer LSP is a special case of the VNT. The VNT is configured
VNT. The virtual network topology is configured by setting up or by setting up or tearing down the lower-layer LSPs. By using GMPLS
tearing down the lower layer LSPs. By using GMPLS signaling and signaling and routing protocols, the VNT can be adapted to traffic
routing protocols, the virtual network topology can be adapted to demands.
traffic demands.
A lower-layer LSP appears as a TE-link in the VNT. Whether the A lower-layer LSP appears as a TE link in the VNT. Whether the
diversely-routed lower-layer LSPs are used or not, the routes of diversely-routed lower-layer LSPs are used or not, the routes of
lower-layer LSPs are hidden from the upper layer in the VNT. Thus, lower-layer LSPs are hidden from the upper layer in the VNT. Thus,
the VNT simplifies the upper-layer routing and traffic engineering the VNT simplifies the upper-layer routing and traffic engineering
decisions by hiding the routes taken by the lower-layer LSPs. decisions by hiding the routes taken by the lower-layer LSPs.
However, hiding the routes of the lower-layer LSPs may lose However, hiding the routes of the lower-layer LSPs may lose important
important information that is needed to make the higher-layer LSPs information that is needed to make the higher-layer LSPs reliable.
reliable. For instance, the routing and traffic engineering in the
IP/MPLS layer does not usually consider how the IP/MPLS TE links
are formed from optical paths that are routed in the fiber layer.
Two optical paths may share the same fiber link in the lower-layer
and therefore they may both fail if the fiber link is cut. Thus the
shared risk properties of the TE links in the VNT must be made
available to the higher layer during path computation. Further, the
topology of the VNT should be designed so that any single fiber cut
does not bisect the VNT. These issues are addressed later in this
document.
Reconfiguration of the virtual network topology may be triggered by For instance, the routing and traffic engineering in the IP/MPLS
traffic demand changes, topology configuration changes, signaling layer does not usually consider how the IP/MPLS TE links are formed
requests from the upper layer, and network failures. For instance, from optical paths that are routed in the fiber layer. Two optical
by reconfiguring the virtual network topology according to the paths may share the same fiber link in the lower-layer and therefore
traffic demand between source and destination node pairs, network they may both fail if the fiber link is cut. Thus the shared risk
performance factors, such as maximum link utilization and residual properties of the TE links in the VNT must be made available to the
capacity of the network, can be optimized. Reconfiguration is higher layer during path computation. Further, the topology of the
performed by computing the new VNT from the traffic demand matrix VNT should be designed so that any single fiber cut does not bisect
and optionally from the current VNT. Exact details are outside the the VNT. These issues are addressed later in this document.
scope of this document. However, this method may be tailored
according to the service provider's policy regarding network Reconfiguration of the VNT may be triggered by traffic demand
performance and quality of service (delay, loss/disruption, changes, topology configuration changes, signaling requests from the
utilization, residual capacity, reliability). upper layer, and network failures. For instance, by reconfiguring
the VNT according to the traffic demand between source and
destination node pairs, network performance factors, such as maximum
link utilization and residual capacity of the network, can be
optimized. Reconfiguration is performed by computing the new VNT
from the traffic demand matrix and optionally from the current VNT.
Exact details are outside the scope of this document. However, this
method may be tailored according to the service provider's policy
regarding network performance and quality of service (delay,
loss/disruption, utilization, residual capacity, reliability).
5. Requirements 5. Requirements
5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes 5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes
The MRN/MLN can consist of single-switching-type-capable and multi- The MRN/MLN can consist of single-switching-type-capable and multi-
switching-type-capable nodes. The path computation mechanism in the switching-type-capable nodes. The path computation mechanism in the
MLN should be able to compute paths consisting of any combination MLN should be able to compute paths consisting of any combination of
of such nodes. such nodes.
Both single-switching-type-capable and multi-switching-type-capable Both single-switching-type-capable and multi-switching-type-capable
(simplex or hybrid) nodes could play the role of layer boundary. (simplex or hybrid) nodes could play the role of layer boundary.
MRN/MLN Path computation should handle TE topologies built of any MRN/MLN path computation should handle TE topologies built of any
combination of nodes. combination of nodes.
5.2. Advertisement of the Available Adjustment Resource 5.2. Advertisement of the Available Adjustment Resources
A hybrid node should maintain resources on its internal links (the A hybrid node should maintain resources on its internal links (the
links required for vertical (layer) integration). Likewise, path links required for vertical integration between layers). Likewise,
computation elements should be prepared to use the availability of path computation elements should be prepared to use information about
termination/ adjustment resources as a constraint in MRN/MLN path the availability of termination and adjustment resources as a
computations to reduce the higher layer LSP setup blocking constraint in MRN/MLN path computations. This would reduce the
probability caused by the lack of necessary termination/adjustment probability that the setup of the higher-layer LSP will be blocked by
resources in the lower layer(s). the lack of necessary termination/adjustment resources in the lower
layers.
The advertisement of the adjustment capability to terminate LSPs of The advertisement of a node's MRN adjustment capabilities (the
lower-region and forward traffic in the upper-region is REQUIRED, ability to terminate LSPs of lower regions and forward the traffic in
as it provides critical information when performing multi-region upper regions) is REQUIRED, as it provides critical information when
path computation. performing multi-region path computation.
The path computation mechanism should cover the case where the The path computation mechanism should cover the case where the
upper-layer links which are directly connected to upper-layer upper-layer links that are directly connected to upper-layer
switching element and the ones which are connected through internal switching elements and the ones that are connected through internal
links between upper-layer element and lower-layer element coexist links between upper-layer element and lower-layer element coexist
(see Section 4.2.1). (see Section 4.2.1).
5.3. Scalability 5.3. Scalability
The MRN/MLN relies on unified routing and traffic engineering The MRN/MLN relies on unified routing and traffic engineering models.
models.
- Unified routing model: By maintaining a single routing protocol - Unified routing model: By maintaining a single routing protocol
instance and a single TE database per LSR, a unified control instance and a single TE database per LSR, a unified control plane
plane model removes the requirement to maintain a dedicated model removes the requirement to maintain a dedicated routing
routing topology per layer, and therefore does not mandate a full topology per layer, and therefore does not mandate a full mesh of
mesh of routing adjacencies per layer. routing adjacencies per layer.
- Unified TE model: The TED in each LSR is populated with TE-links - Unified TE model: The TED in each LSR is populated with TE links
from all layers of all regions (TE link interfaces on multiple- from all layers of all regions (TE link interfaces on multiple-
switching-capability LSRs can be advertised with multiple ISCDs). switching-type-capable LSRs can be advertised with multiple ISCDs).
This may lead to an increase in the amount of information that This may lead to an increase in the amount of information that has
has to be flooded and stored within the network. to be flooded and stored within the network.
Furthermore, path computation times, which may be of great Furthermore, path computation times, which may be of great importance
importance during restoration, will depend on the size of the TED. during restoration, will depend on the size of the TED.
Thus MRN/MLN routing mechanisms MUST be designed to scale well with Thus, MRN/MLN routing mechanisms MUST be designed to scale well with
an increase of any of the following: an increase of any of the following:
- Number of nodes - Number of nodes
- Number of TE-links (including FA-LSPs) - Number of TE links (including FA-LSPs)
- Number of LSPs - Number of regions and layers - Number of LSPs
- Number of ISCDs per TE-link. - Number of regions and layers
- Number of ISCDs per TE link.
Further, design of the routing protocols MUST NOT prevent TE Further, design of the routing protocols MUST NOT prevent TE
information filtering based on ISCDs. The path computation information filtering based on ISCDs. The path computation mechanism
mechanism and the signaling protocol SHOULD be able to operate on and the signaling protocol SHOULD be able to operate on partial TE
partial TE information. information.
Since TE Links can advertise multiple Interface Switching Since TE links can advertise multiple Interface Switching
Capabilities (ISCs), the number of links can be limited (by Capabilities (ISCs), the number of links can be limited (by
combination) by using specific topological maps referred to as VNTs combination) by using specific topological maps referred to as VNTs
(Virtual Network Topologies). The introduction of virtual (Virtual Network Topologies). The introduction of virtual
topological maps leads us to consider the concept of emulation of topological maps leads us to consider the concept of emulation of
data plane overlays. data plane overlays.
5.4. Stability 5.4. Stability
Path computation is dependent on the network topology and Path computation is dependent on the network topology and associated
associated link state. The path computation stability of an upper link state. The path computation stability of an upper layer may be
layer may be impaired if the VNT changes frequently and/or if the impaired if the VNT changes frequently and/or if the status and TE
status and TE parameters (the TE metric, for instance) of links in parameters (the TE metric, for instance) of links in the VNT changes
the VNT changes frequently. In this context, robustness of the VNT frequently. In this context, robustness of the VNT is defined as the
is defined as the capability to smooth changes that may occur and capability to smooth changes that may occur and avoid their
avoid their propagation into higher layers. Changes to the VNT may propagation into higher layers. Changes to the VNT may be caused by
be caused by the creation, deletion, or modification of LSPs. the creation, deletion, or modification of LSPs.
Protocol mechanisms MUST be provided to enable creation, deletion, Protocol mechanisms MUST be provided to enable creation, deletion,
and modification of LSPs triggered through operational actions. and modification of LSPs triggered through operational actions.
Protocol mechanisms SHOULD be provided to enable similar functions Protocol mechanisms SHOULD be provided to enable similar functions
triggered by adjacent layers. Protocol mechanisms MAY be provided triggered by adjacent layers. Protocol mechanisms MAY be provided to
to enable similar functions to adapt to the environment changes enable similar functions to adapt to the environment changes such as
such as traffic demand changes, topology changes, and network traffic demand changes, topology changes, and network failures.
failures. Routing robustness should be traded with adaptability of Routing robustness should be traded with adaptability of those
those changes. changes.
5.5. Disruption Minimization 5.5. Disruption Minimization
When reconfiguring the VNT according to a change in traffic demand, When reconfiguring the VNT according to a change in traffic demand,
the upper-layer LSP might be disrupted. Such disruption to the the upper-layer LSP might be disrupted. Such disruption to the upper
upper layers must be minimized. layers must be minimized.
When residual resource decreases to a certain level, some lower When residual resource decreases to a certain level, some lower-layer
layer LSPs may be released according to local or network policies. LSPs may be released according to local or network policies. There
There is a trade-off between minimizing the amount of resource is a trade-off between minimizing the amount of resource reserved in
reserved in the lower layer and disrupting higher layer traffic the lower layer and disrupting higher-layer traffic (i.e., moving the
(i.e. moving the traffic to other TE-LSPs so that some LSPs can be traffic to other TE-LSPs so that some LSPs can be released). Such
released). Such traffic disruption may be allowed, but MUST be traffic disruption may be allowed, but MUST be under the control of
under the control of policy that can be configured by the operator. policy that can be configured by the operator. Any repositioning of
Any repositioning of traffic MUST be as non-disruptive as possible traffic MUST be as non-disruptive as possible (for example, using
(for example, using make-before-break). make-before-break).
5.6. LSP Attribute Inheritance 5.6. LSP Attribute Inheritance
TE-Link parameters should be inherited from the parameters of the TE link parameters should be inherited from the parameters of the LSP
LSP that provides the TE-link, and so from the TE-links in the that provides the TE link, and so from the TE links in the lower
lower layer that are traversed by the LSP. layer that are traversed by the LSP.
These include: These include:
- Interface Switching Capability - Interface Switching Capability
- TE metric - TE metric
- Maximum LSP bandwidth per priority level - Maximum LSP bandwidth per priority level
- Unreserved bandwidth for all priority levels - Unreserved bandwidth for all priority levels
- Maximum Reservable bandwidth - Maximum reservable bandwidth
- Protection attribute - Protection attribute
- Minimum LSP bandwidth (depending on the Switching Capability) - Minimum LSP bandwidth (depending on the switching capability)
- SRLG - SRLG
Inheritance rules must be applied based on specific policies. Inheritance rules must be applied based on specific policies.
Particular attention should be given to the inheritance of TE Particular attention should be given to the inheritance of the TE
metric (which may be other than a strict sum of the metrics of the metric (which may be other than a strict sum of the metrics of the
component TE links at the lower layer), protection attributes, and component TE links at the lower layer), protection attributes, and
SRLG. SRLG.
As described earlier, hiding the routes of the lower-layer LSPs may As described earlier, hiding the routes of the lower-layer LSPs may
lose important information necessary to make LSPs in the higher lose important information necessary to make LSPs in the higher-layer
layer network reliable. SRLGs may be used to identify which lower- network reliable. SRLGs may be used to identify which lower-layer
layer LSPs share the same failure risk so that the potential risk LSPs share the same failure risk so that the potential risk of the
of the VNT becoming disjoint can be minimized, and so that resource VNT becoming disjoint can be minimized, and so that resource-disjoint
disjoint protection paths can be set up in the higher layer. How to protection paths can be set up in the higher layer. How to inherit
inherit the SRLG information from the lower layer to the upper the SRLG information from the lower layer to the upper layer needs
layer needs more discussion and is out of scope of this document. more discussion and is out of scope of this document.
5.7. Computing Paths With and Without Nested Signaling 5.7. Computing Paths with and without Nested Signaling
Path computation can take into account LSP region and layer Path computation can take into account LSP region and layer
boundaries when computing a path for an LSP. Path computation may boundaries when computing a path for an LSP. Path computation may
restrict the path taken by an LSP to only the links whose interface restrict the path taken by an LSP to only the links whose interface
switching capability is PSC. For example, suppose that a TDM-LSP is switching capability is PSC. For example, suppose that a TDM-LSP is
routed over the topology composed of TE links of the same TDM layer. routed over the topology composed of TE links of the same TDM layer.
In calculating the path for the LSP, the TED may be filtered to In calculating the path for the LSP, the TED may be filtered to
include only links where both end include requested LSP switching include only links where both end include requested LSP switching
type. In this way hierarchical routing is done by using a TED type. In this way hierarchical routing is done by using a TED
filtered with respect to switching capability (that is, with filtered with respect to switching capability (that is, with respect
respect to particular layer). to particular layer).
If triggered signaling is allowed, the path computation mechanism If triggered signaling is allowed, the path computation mechanism may
may produce a route containing multiple layers/regions. The path is produce a route containing multiple layers/regions. The path is
computed over the multiple layers/regions even if the path is not computed over the multiple layers/regions even if the path is not
"connected" in the same layer as the endpoints of the path exist. "connected" in the same layer as where the endpoints of the path
Note that here we assume that triggered signaling will be invoked exist. Note that here we assume that triggered signaling will be
to make the path "connected", when the upper-layer signaling invoked to make the path "connected", when the upper-layer signaling
request arrives at the boundary node. request arrives at the boundary node.
The upper-layer signaling request MAY contain an ERO (Explicit The upper-layer signaling request MAY contain an ERO (Explicit Route
Route Object) that includes only hops in the upper layer, in which Object) that includes only hops in the upper layer; in which case,
case the boundary node is responsible for triggered creation of the the boundary node is responsible for triggered creation of the
lower-layer FA-LSP using a path of its choice, or for the selection lower-layer FA-LSP using a path of its choice, or for the selection
of any available lower layer LSP as a data link for the higher of any available lower-layer LSP as a data link for the higher layer.
layer. This mechanism is appropriate for environments where the TED This mechanism is appropriate for environments where the TED is
is filtered in the higher layer, where separate routing instances filtered in the higher layer, where separate routing instances are
are used per layer, or where administrative policies prevent the used per layer, or where administrative policies prevent the higher
higher layer from specifying paths through the lower layer. layer from specifying paths through the lower layer.
Obviously, if the lower layer LSP has been advertised as a TE link Obviously, if the lower-layer LSP has been advertised as a TE link
(virtual or real) into the higher layer, then the higher layer (virtual or real) into the higher layer, then the higher-layer
signaling request MAY contain the TE link identifier and so signaling request MAY contain the TE link identifier and so indicate
indicate the lower layer resources to be used. But in this case, the lower-layer resources to be used. But in this case, the path of
the path of the lower layer LSP can be dynamically changed by the the lower-layer LSP can be dynamically changed by the lower layer at
lower layer at any time. any time.
Alternatively, the upper-layer signaling request MAY contain an ERO Alternatively, the upper-layer signaling request MAY contain an ERO
specifying the lower layer FA-LSP route. In this case, the boundary specifying the lower-layer FA-LSP route. In this case, the boundary
node MAY decide whether it should use the path contained in the node MAY decide whether it should use the path contained in the
strict ERO or re-compute the path within the lower-layer. strict ERO or re-compute the path within the lower layer.
Even in the case that the lower-layer FA-LSPs are already Even in the case that the lower-layer FA-LSPs are already
established, a signaling request may also be encoded as a loose ERO. established, a signaling request may also be encoded as a loose ERO.
In this situation, it is up to the boundary node to decide whether In this situation, it is up to the boundary node to decide whether it
it should create a new lower-layer FA-LSP or it should use an should create a new lower-layer FA-LSP or it should use an existing
existing lower-layer FA-LSPs. lower-layer FA-LSP.
The lower-layer FA-LSP can be advertised just as an FA-LSP in the The lower-layer FA-LSP can be advertised just as an FA-LSP in the
upper-layer or an IGP adjacency can be brought up on the lower- upper layer or an IGP adjacency can be brought up on the lower-layer
layer FA-LSP. FA-LSP.
5.8. LSP Resource Utilization 5.8. LSP Resource Utilization
Resource usage in all layers should be optimized as a whole (i.e., Resource usage in all layers should be optimized as a whole (i.e.,
across all layers), in a coordinated manner, (i.e., taking all across all layers), in a coordinated manner (i.e., taking all layers
layers into account). The number of lower-layer LSPs carrying into account). The number of lower-layer LSPs carrying upper-layer
upper-layer LSPs should be minimized (note that multiple LSPs may LSPs should be minimized (note that multiple LSPs may be used for
be used for load balancing). Lower-layer LSPs that could have their load balancing). Lower-layer LSPs that could have their traffic
traffic re-routed onto other LSPs are unnecessary and should be re-routed onto other LSPs are unnecessary and should be avoided.
avoided.
5.8.1. FA-LSP Release and Setup 5.8.1. FA-LSP Release and Setup
If there is low traffic demand, some FA-LSPs that do not carry any If there is low traffic demand, some FA-LSPs that do not carry any
higher-layer LSP may be released so that lower-layer resources are higher-layer LSP may be released so that lower-layer resources are
released and can be assigned to other uses. Note that if a small released and can be assigned to other uses. Note that if a small
fraction of the available bandwidth of an FA-LSP is still in use, fraction of the available bandwidth of an FA-LSP is still in use, the
the nested LSPs can also be re-routed to other FA-LSPs (optionally nested LSPs can also be re-routed to other FA-LSPs (optionally using
using the make-before-break technique) to completely free up the the make-before-break technique) to completely free up the FA-LSP.
FA-LSP. Alternatively, unused FA-LSPs may be retained for future Alternatively, unused FA-LSPs may be retained for future use.
use. Release or retention of underutilized FA-LSPs is a policy Release or retention of underutilized FA-LSPs is a policy decision.
decision.
As part of the re-optimization process, the solution MUST allow As part of the re-optimization process, the solution MUST allow
rerouting of an FA-LSP while keeping interface identifiers of rerouting of an FA-LSP while keeping interface identifiers of
corresponding TE links unchanged. Further, this process MUST be corresponding TE links unchanged. Further, this process MUST be
possible while the FA-LSP is carrying traffic (higher layer LSPs) possible while the FA-LSP is carrying traffic (higher-layer LSPs)
with minimal disruption to the traffic. with minimal disruption to the traffic.
Additional FA-LSPs may also be created based on policy, which might Additional FA-LSPs may also be created based on policy, which might
consider residual resources and the change of traffic demand across consider residual resources and the change of traffic demand across
the region. By creating the new FA-LSPs, the network performance the region. By creating the new FA-LSPs, the network performance
such as maximum residual capacity may increase. such as maximum residual capacity may increase.
As the number of FA-LSPs grows, the residual resource may decrease. As the number of FA-LSPs grows, the residual resources may decrease.
In this case, re-optimization of FA-LSPs may be invoked according In this case, re-optimization of FA-LSPs may be invoked according to
to policy. policy.
Any solution MUST include measures to protect against network Any solution MUST include measures to protect against network
destabilization caused by the rapid setup and teardown of LSPs as destabilization caused by the rapid setup and teardown of LSPs as
traffic demand varies near a threshold. traffic demand varies near a threshold.
Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly
advertise the LSP as a TE link and to coordinate into which routing advertise the LSP as a TE link and to coordinate into which routing
instances the TE link should be advertised. instances the TE link should be advertised.
5.8.2. Virtual TE-Links 5.8.2. Virtual TE Links
It may be considered disadvantageous to fully instantiate (i.e. It may be considered disadvantageous to fully instantiate (i.e.,
pre- provision) the set of lower layer LSPs that provide the VNT pre-provision) the set of lower-layer LSPs that provide the VNT since
since this might reserve bandwidth that could be used for other this might reserve bandwidth that could be used for other LSPs in the
LSPs in the absence of upper-layer traffic. absence of upper-layer traffic.
However, in order to allow path computation of upper-layer LSPs However, in order to allow path computation of upper-layer LSPs
across the lower-layer, the lower-layer LSPs may be advertised into across the lower layer, the lower-layer LSPs may be advertised into
the upper-layer as though they had been fully established, but the upper layer as though they had been fully established, but
without actually establishing them. Such TE links that represent without actually establishing them. Such TE links that represent the
the possibility of an underlying LSP are termed "virtual TE-links." possibility of an underlying LSP are termed "virtual TE links". It
It is an implementation choice at a layer boundary node whether to is an implementation choice at a layer boundary node whether to
create real or virtual TE-links, and the choice if available in an create real or virtual TE links, and the choice (if available in an
implementation MUST be under the control of operator policy. Note implementation) MUST be under the control of operator policy. Note
that there is no requirement to support the creation of virtual TE- that there is no requirement to support the creation of virtual TE
links, since real TE-links (with established LSPs) may be used, and links, since real TE links (with established LSPs) may be used. Even
even if there are no TE-links (virtual or real) advertised to the if there are no TE links (virtual or real) advertised to the higher
higher layer, it is possible to route a higher layer LSP into a layer, it is possible to route a higher-layer LSP into a lower layer
lower layer on the assumptions that proper hierarchical LSPs in the on the assumption that proper hierarchical LSPs in the lower layer
lower layer will be dynamically created (triggered) as needed. will be dynamically created (triggered) as needed.
If an upper-layer LSP that makes use of a virtual TE-Link is set up, If an upper-layer LSP that makes use of a virtual TE link is set up,
the underlying LSP MUST be immediately signaled in the lower layer. the underlying LSP MUST be immediately signaled in the lower layer.
If virtual TE-Links are used in place of pre-established LSPs, the If virtual TE links are used in place of pre-established LSPs, the TE
TE-links across the upper-layer can remain stable using pre- links across the upper layer can remain stable using pre-computed
computed paths while wastage of bandwidth within the lower-layer paths while wastage of bandwidth within the lower layer and
and unnecessary reservation of adaptation resource at the border unnecessary reservation of adaptation resources at the border nodes
nodes can be avoided. can be avoided.
The solution SHOULD provide operations to facilitate the build-up The solution SHOULD provide operations to facilitate the build-up of
of such virtual TE-links, taking into account the (forecast) such virtual TE links, taking into account the (forecast) traffic
traffic demand and available resource in the lower-layer. demand and available resources in the lower layer.
Virtual TE-links can be added, removed or modified dynamically (by Virtual TE links can be added, removed, or modified dynamically (by
changing their capacity) according to the change of the (forecast) changing their capacity) according to the change of the (forecast)
traffic demand and the available resource in the lower-layer. It traffic demand and the available resources in the lower layer. It
MUST be possible to add, remove, and modify virtual TE-links in a MUST be possible to add, remove, and modify virtual TE links in a
dynamic way. dynamic way.
Any solution MUST include measures to protect against network Any solution MUST include measures to protect against network
destabilization caused by the rapid changes in the virtual network destabilization caused by the rapid changes in the VNT as traffic
topology as traffic demand varies near a threshold. demand varies near a threshold.
The concept of the VNT can be extended to allow the virtual TE- The concept of the VNT can be extended to allow the virtual TE links
links to form part of the VNT. The combination of the fully to form part of the VNT. The combination of the fully provisioned TE
provisioned TE-links and the virtual TE-links defines the VNT links and the virtual TE links defines the VNT provided by the lower
provided by the lower layer. The VNT can be changed by setting up layer. The VNT can be changed by setting up and/or tearing down
and/or tearing down virtual TE links as well as by modifying real virtual TE links as well as by modifying real links (i.e., the fully
links (i.e., the fully provisioned LSPs). How to design the VNT and provisioned LSPs). How to design the VNT and how to manage it are
how to manage it are out of scope of this document. out of scope of this document.
In some situations, selective advertisement of the preferred In some situations, selective advertisement of the preferred
connectivity among a set of border nodes between layers may be connectivity among a set of border nodes between layers may be
appropriate. Further decreasing the number of advertisement of the appropriate. Further decreasing the number of advertisements of the
virtual connectivity can be achieved by abstracting the topology virtual connectivity can be achieved by abstracting the topology
(between border nodes) using models similar to those detailed in (between border nodes) using models similar to those detailed in
[RFC4847]. [RFC4847].
5.9. Verification of the LSPs 5.9. Verification of the LSPs
When a lower layer LSP is established for use as a data link by a When a lower-layer LSP is established for use as a data link by a
higher layer, the LSP may be verified for correct connectivity and higher layer, the LSP may be verified for correct connectivity and
data integrity before it is made available for use. Such mechanisms data integrity before it is made available for use. Such mechanisms
are data technology-specific and are beyond the scope of this are data-technology-specific and are beyond the scope of this
document, but the GMPLS protocols SHOULD provide mechanisms for the document, but the GMPLS protocols SHOULD provide mechanisms for the
coordination of data link verification. coordination of data link verification.
5.10. Management 5.10. Management
A MRN/MLN requires management capabilities. Operators need to have An MRN/MLN requires management capabilities. Operators need to have
the same level of control and management for switches and links in the same level of control and management for switches and links in
the network that they would have in a single layer or single region the network that they would have in a single-layer or single-region
network. network.
We can consider two different operational models: (1) Per-layer We can consider two different operational models: (1) per-layer
management entities, (2) Cross-layer management entities. management entities and (2) cross-layer management entities.
Regarding per-layer management entities, it is possible for the MLN Regarding per-layer management entities, it is possible for the MLN
to be managed entirely as separate layers although that somewhat to be managed entirely as separate layers, although that somewhat
defeats the objective of defining a single multi-layer network. In defeats the objective of defining a single multi-layer network. In
this case, separate management systems would be operated for each this case, separate management systems would be operated for each
layer, and those systems would be unaware of the fact that the layers layer, and those systems would be unaware of the fact that the layers
were closely coupled in the control plane. In such a deployment, as were closely coupled in the control plane. In such a deployment, as
LSPs were automatically set up as the result of control plane LSPs were automatically set up as the result of control plane
requests from other layers (for example, triggered signaling), the requests from other layers (for example, triggered signaling), the
management applications would need to register the creation of the management applications would need to register the creation of the
new LSPs and the depletion of network resources. Emphasis would be new LSPs and the depletion of network resources. Emphasis would be
placed on the layer boundary nodes to report the activity to the placed on the layer boundary nodes to report the activity to the
management applications. management applications.
A more likely scenario is to apply a closer coupling of layer A more likely scenario is to apply a closer coupling of layer
management systems with cross-layer management entities. This might management systems with cross-layer management entities. This might
be achieved through a unified management system capable of operating be achieved through a unified management system capable of operating
multiple layers, or by a meta-management system that coordinates the multiple layers, or by a meta-management system that coordinates the
operation of separate management systems each responsible for operation of separate management systems each responsible for
individual layers. The former case might only be possible with the individual layers. The former case might only be possible with the
development of new management systems, while the latter is feasible development of new management systems, while the latter is feasible
through the coordination of existing network management tools. through the coordination of existing network management tools.
Note that when a layer boundary also forms an administrative boundary Note that when a layer boundary also forms an administrative
it is highly unlikely that there will be unified multi-layer boundary, it is highly unlikely that there will be unified multi-
management. In this case, the layers will be separately managed by layer management. In this case, the layers will be separately
the separate administrative entities, but there may be some "leakage" managed by the separate administrative entities, but there may be
of information between the administrations in order to facilitate the some "leakage" of information between the administrations in order to
operation of the MLN. For example, the management system in the lower facilitate the operation of the MLN. For example, the management
layer network might automatically issue reports on resource system in the lower-layer network might automatically issue reports
availability (coincident with TE routing information), and alarm on resource availability (coincident with TE routing information) and
events. alarm events.
This discussion comes close to an examination of how a VNT might be This discussion comes close to an examination of how a VNT might be
managed and operated. As noted in Section 5.8, issues of how to managed and operated. As noted in Section 5.8, issues of how to
design and manage a VNT are out of scope for this document, but it design and manage a VNT are out of scope for this document, but it
should be understood, that the VNT is a client layer construct built should be understood that the VNT is a client-layer construct built
from server layer resources. This means that the operation of a VNT from server-layer resources. This means that the operation of a VNT
is a collaborative activity between layers. This activity is possible is a collaborative activity between layers. This activity is
even if the layers are from separate administrations, but in this possible even if the layers are from separate administrations, but in
case the activity may also have commercial implications. this case the activity may also have commercial implications.
MIB modules exist for the modeling and management of GMPLS networks MIB modules exist for the modeling and management of GMPLS networks
[RFC4802], [RFC4803]. Some deployments of GMPLS networks may choose [RFC4802] [RFC4803]. Some deployments of GMPLS networks may choose
to use MIB modules to operate individual network layers. In these to use MIB modules to operate individual network layers. In these
cases, operators may desire to coordinate layers through a further cases, operators may desire to coordinate layers through a further
MIB module that could be developed. Multi-layer protocol solutions MIB module that could be developed. Multi-layer protocol solutions
(that is solutions where a single control plane instance operates in (that is, solutions where a single control plane instance operates in
more than one layer) SHOULD be manageable through MIB modules. A more than one layer) SHOULD be manageable through MIB modules. A
further MIB module to coordinate multiple network layers with this further MIB module to coordinate multiple network layers with this
control plane MIB module may be produced. control plane MIB module may be produced.
OAM tools are important to the successful deployment of all networks. Operations and Management (OAM) tools are important to the successful
deployment of all networks.
OAM requirements for GMPLS networks are described in [GMPLS-OAM]. OAM requirements for GMPLS networks are described in [GMPLS-OAM].
That document points out that protocol solutions for individual That document points out that protocol solutions for individual
network layers should include mechanisms for OAM or to make use of network layers should include mechanisms for OAM or make use of OAM
OAM features inherent in the physical media of the layers. Further features inherent in the physical media of the layers. Further
discussion of individual layer OAM is out of scope of this document. discussion of individual-layer OAM is out of scope of this document.
When operating OAM in a MLN, consideration must be given to how to When operating OAM in a MLN, consideration must be given to how to
provide OAM for end-to-end LSPs that cross domain boundaries and how provide OAM for end-to-end LSPs that cross layer boundaries (that may
to coordinate errors and alarms detected in a server layer that need also be administrative boundaries) and how to coordinate errors and
to be reported to the client layer. These operational choices MUST be alarms detected in a server layer that need to be reported to the
left open to the service provider and so MLN protocol solutions MUST client layer. These operational choices MUST be left open to the
include the following features: service provider and so MLN protocol solutions MUST include the
following features:
- Within the context and technology capabilities of the highest - Within the context and technology capabilities of the highest
technology layer of an LSP (i.e., the technology layer of the first technology layer of an LSP (i.e., the technology layer of the first
hop), it MUST be possible to enable end-to-end OAM on a MLN LSP. hop), it MUST be possible to enable end-to-end OAM on a MLN LSP.
This function appears to the ingress LSP as normal LSP-based OAM This function appears to the ingress LSP as normal LSP-based OAM
[GMPLS-OAM], but at layer boundaries, depending on the technique [GMPLS-OAM], but at layer boundaries, depending on the technique
used to span the lower layers, client layer OAM operations may need used to span the lower layers, client-layer OAM operations may need
to mapped to server layer OAM operations. Most such requirements to mapped to server-layer OAM operations. Most such requirements
are highly dependent on the OAM facilities of the data plane are highly dependent on the OAM facilities of the data plane
technologies of client and server layers. However, control plane technologies of client and server layers. However, control plane
mechanisms used in the client layer per [GMPLS-OAM] MUST map and mechanisms used in the client layer per [GMPLS-OAM] MUST map and
enable OAM in the server layer. enable OAM in the server layer.
- OAM operation enabled per [GMPLS-OAM] in a client layer for an LSP - OAM operation enabled per [GMPLS-OAM] in a client layer for an LSP
MUST operate for that LSP along its entire length. This means that MUST operate for that LSP along its entire length. This means that
if an LSP crosses a domain of a lower layer technology, the client if an LSP crosses a domain of a lower-layer technology, the
layer OAM operation must operate seamlessly within the client layer client-layer OAM operation must operate seamlessly within the
at both ends of the client layer LSP. client layer at both ends of the client-layer LSP.
- OAM function operating within a server layer MUST be controllable - OAM functions operating within a server layer MUST be controllable
from the client layer such that the server layer LSP(s) that from the client layer such that the server-layer LSP(s) that
support a client layer LSP have OAM enabled at the request of the support a client-layer LSP have OAM enabled at the request of the
client layer. Such control SHOULD be subject to policy at the layer client layer. Such control SHOULD be subject to policy at the
boundary just as automatic provisioning and LSP requests to the layer boundary, just as automatic provisioning and LSP requests to
server layer are subject to policy. the server layer are subject to policy.
- The status including errors and alarms applicable to a server layer - The status including errors and alarms applicable to a server-layer
LSP MUST be available to the client layer. This information SHOULD LSP MUST be available to the client layer. This information SHOULD
be configurable to be automatically notified to the client layer at be configurable to be automatically notified to the client layer at
the layer boundary and SHOULD be subject to policy so that the the layer boundary and SHOULD be subject to policy so that the
server layer may filter or hide information supplied to the client server layer may filter or hide information supplied to the client
layer. Furthermore, the client layer SHOULD be able to select to layer. Furthermore, the client layer SHOULD be able to select to
not receive any or all such information. not receive any or all such information.
Note that the interface between layers lies within network nodes and Note that the interface between layers lies within network nodes and
is, therefore, not necessarily the subject of a protocol is, therefore, not necessarily the subject of a protocol
specification. Implementations MAY use standardized techniques (such specification. Implementations MAY use standardized techniques (such
as MIB modules) to convey status information (such as errors and as MIB modules) to convey status information (such as errors and
alarms) between layers, but that is out of scope for this document. alarms) between layers, but that is out of scope for this document.
6. Security Considerations 6. Security Considerations
The MLN/MRN architecture does not introduce any new security The MLN/MRN architecture does not introduce any new security
requirements over the general GMPLS architecture described in requirements over the general GMPLS architecture described in
[RFC3945]. Additional security considerations form MPLS and GMPLS [RFC3945]. Additional security considerations form MPLS and GMPLS
networks are described in [MPLS-SEC]. networks are described in [MPLS-SEC].
However, where the separate layers of a MLN/MRN network are However, where the separate layers of an MLN/MRN network are operated
operated as different administrative domains, additional security as different administrative domains, additional security
considerations may be given to the mechanisms for allowing inter- considerations may be given to the mechanisms for allowing LSP setup
layer LSP setup, for triggering lower-layer LSPs, or for VNT crossing one or more layer boundaries, for triggering lower-layer
management. Similarly, consideration may be given to the amount of LSPs, or for VNT management. Similarly, consideration may be given
information shared between administrative domains, and the trade- to the amount of information shared between administrative domains,
off between multi-layer TE and confidentiality of information and the trade-off between multi-layer TE and confidentiality of
belonging to each administrative domain. information belonging to each administrative domain.
It is expected that solution documents will include a full analysis It is expected that solution documents will include a full analysis
of the security issues that any protocol extensions introduce. of the security issues that any protocol extensions introduce.
7. IANA Considerations 7. Acknowledgements
This informational document makes no requests to IANA for action.
8. Acknowledgements
The authors would like to thank Adrian Farrel and the participants The authors would like to thank Adrian Farrel and the participants of
of ITU-T Study Group 15 Question 14 for their careful review. The ITU-T Study Group 15, Question 14 for their careful review. The
authors would like to thank the IESG review team for rigorous review: authors would like to thank the IESG review team for rigorous review:
special thanks to Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu, special thanks to Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu,
and Dave Ward. and Dave Ward.
9. References 8. References
9.1. Normative Reference 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004. Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4202] Kompella, K., and Rekhter, Y., "Routing Extensions in [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Support of Generalized Multi-Protocol Label Switching Extensions in Support of Generalized Multi-Protocol Label
(GMPLS)," RFC4202, October 2005. Switching (GMPLS)", RFC 4202, October 2005.
[RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
(LSP) Hierarchy with Generalized Multi-Protocol Label Hierarchy with Generalized Multi-Protocol Label Switching
Switching (GMPLS) Traffic Engineering (TE)," RFC4206, (GMPLS) Traffic Engineering (TE)", RFC 4206, October
Oct. 2005. 2005.
[RFC4397] Bryskin, I., and Farrel, A., "A Lexicography for the [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON) ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, February 2006. Architecture", RFC 4397, February 2006.
[RFC4726] Farrel, A., Vasseur, JP., and Ayyangar, A., "A [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
Framework for Inter-Domain Multiprotocol Label for Inter-Domain Multiprotocol Label Switching Traffic
Switching Traffic Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
9.2. Informative References 8.2. Informative References
[DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and
and Ali, Z., "Procedures for Dynamically Signaled Z. Ali, "Procedures for Dynamically Signaled Hierarchical
Hierarchical Label Switched Paths", draft-ietf-ccamp- Label Switched Paths", Work in Progress, February 2008.
lsp-hierarchy-bis, work in progress.
[MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, [MRN-EVAL] Le Roux, J.L., Ed., and D. Papadimitriou, Ed.,
D., Shiomoto, K., Vigoureux, M., "Evaluation of "Evaluation of existing GMPLS Protocols against Multi
Existing GMPLS Protocols Against Multi-Layer and Layer and Multi Region Networks (MLN/MRN)", Work in
Multi-Region Network (MLN/MRN) Requirements", draft- Progress, December 2007.
ietf-ccamp-gmpls-mln-eval, work in progress.
[RFC5146] K. Kumaki (Editor), "Interworking Requirements to [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
Support Operation of MPLS-TE over GMPLS Networks", Operation of MPLS-TE over GMPLS Networks", RFC 5146,
RFC 5146, March 2008. March 2008.
[MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and [MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- Networks", Work in Progress, February 2008.
security-framework, work in progress.
[RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Multiprotocol Label Switching (GMPLS) Traffic Engineering
Engineering Management Information Base", RFC 4802, Management Information Base", RFC 4802, February 2007.
February 2007.
[RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized [RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Label Switching Multiprotocol Label Switching (GMPLS) Label Switching
Router (LSR) Management Information Base", RFC 4803, Router (LSR) Management Information Base", RFC 4803,
February 2007. February 2007.
[RFC4847] T. Takeda (Editor), " Framework and Requirements for [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
Layer 1 Virtual Private Networks", RFC 4847, April 2007. Virtual Private Networks", RFC 4847, April 2007.
[RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing [RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S.,
Extensions for Discovery of Multiprotocol (MPLS) Previdi, S., Psenak, P., and P. Mabbey, "Routing
Label Switch Router (LSR) Traffic Engineering (TE) Extensions for Discovery of Multiprotocol (MPLS) Label
Mesh Membership", RFC 4972, July 2007. Switch Router (LSR) Traffic Engineering (TE) Mesh
Membership", RFC 4972, July 2007.
[GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and Farrel, A., "OAM [GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and A. Farrel, "OAM
Requirements for Generalized Multi-Protocol Label Requirements for Generalized Multi-Protocol Label
Switching (GMPLS) Networks", draft-ietf-ccamp-gmpls-oam- Switching (GMPLS) Networks", Work in Progress, October
requirements, work in progress. 2007.
10. Authors' Addresses 9. Contributors' Addresses
Eiji Oki
NTT Network Service Systems Laboratories
3-9-11 Midori-cho, Musashino-shi
Tokyo 180-8585
Japan
Phone: +81 422 59 3441
EMail: oki.eiji@lab.ntt.co.jp
Ichiro Inoue
NTT Network Service Systems Laboratories
3-9-11 Midori-cho, Musashino-shi
Tokyo 180-8585
Japan
Phone: +81 422 59 3441
EMail: ichiro.inoue@lab.ntt.co.jp
Emmanuel Dotaro
Alcatel-Lucent
Route de Villejust
91620 Nozay
France
Phone: +33 1 3077 2670
EMail: emmanuel.dotaro@alcatel-lucent.fr
Authors' Addresses
Kohei Shiomoto Kohei Shiomoto
NTT Network Service Systems Laboratories NTT Network Service Systems Laboratories
3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan 3-9-11 Midori-cho, Musashino-shi
Email: shiomoto.kohei@lab.ntt.co.jp Tokyo 180-8585
Japan
EMail: shiomoto.kohei@lab.ntt.co.jp
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50, Copernicuslaan 50
B-2018 Antwerpen, Belgium B-2018 Antwerpen
Belgium
Phone : +32 3 240 8491 Phone : +32 3 240 8491
Email: dimitri.papadimitriou@alcatel-lucent.be EMail: dimitri.papadimitriou@alcatel-lucent.be
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom R&D, France Telecom R&D
Av Pierre Marzin, Av Pierre Marzin
22300 Lannion, France 22300 Lannion
Email: jeanlouis.leroux@orange-ft.com France
EMail: jeanlouis.leroux@orange-ftgroup.com
Martin Vigoureux Martin Vigoureux
Alcatel-Lucent Alcatel-Lucent
Route de Nozay, 91461 Marcoussis cedex, France Route de Villejust
Phone: +33 (0)1 69 63 18 52 91620 Nozay
Email: martin.vigoureux@alcatel-lucent.fr France
Phone: +33 1 3077 2669
EMail: martin.vigoureux@alcatel-lucent.fr
Deborah Brungard Deborah Brungard
AT&T AT&T
Rm. D1-3C22 - 200 Rm. D1-3C22 - 200
S. Laurel Ave., Middletown, NJ 07748, USA S. Laurel Ave.
Middletown, NJ 07748
USA
Phone: +1 732 420 1573 Phone: +1 732 420 1573
Email: dbrungard@att.com EMail: dbrungard@att.com
11. Contributors' Addresses Full Copyright Statement
Eiji Oki Copyright (C) The IETF Trust (2008).
NTT Network Service Systems Laboratories
3-9-11 Midori-cho, Musashino-shi,
Tokyo 180-8585,
Japan
Phone: +81 422 59 3441
Email: oki.eiji@lab.ntt.co.jp
Ichiro Inoue This document is subject to the rights, licenses and restrictions
NTT Network Service Systems Laboratories contained in BCP 78, and except as set forth therein, the authors
3-9-11 Midori-cho, retain all their rights.
Musashino-shi,
Tokyo 180-8585,
Japan
Phone: +81 422 59 3441
Email: ichiro.inoue@lab.ntt.co.jp
Emmanuel Dotaro This document and the information contained herein are provided on an
Alcatel-Lucent "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
Route de Nozay, OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
91461 Marcoussis cedex, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
France OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
Phone : +33 1 6963 4723 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
Email: emmanuel.dotaro@alcatel-lucent.fr WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Intellectual Property Considerations Intellectual Property
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 Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
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 attempt made to obtain a general license or permission for the use of
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 specification can be obtained from the IETF on-line IPR repository at
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 ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
13. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
 End of changes. 178 change blocks. 
724 lines changed or deleted 720 lines changed or added

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