draft-ietf-ccamp-gmpls-mln-reqs-03.txt | draft-ietf-ccamp-gmpls-mln-reqs-04.txt | |||
---|---|---|---|---|
Network Working Group Kohei Shiomoto (NTT) | Network Working Group Kohei Shiomoto (NTT) | |||
Internet-Draft Dimitri Papadimitriou (Alcatel) | Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) | |||
Intended Status: Informational Jean-Louis Le Roux (France Telecom) | Intended Status: Informational Jean-Louis Le Roux (France Telecom) | |||
Martin Vigoureux (Alcatel) | Martin Vigoureux (Alcatel-Lucent) | |||
Deborah Brungard (AT&T) | Deborah Brungard (AT&T) | |||
Expires: February 2008 August 2007 | ||||
Requirements for GMPLS-based multi-region and | Requirements for GMPLS-based multi-region and | |||
multi-layer networks (MRN/MLN) | multi-layer networks (MRN/MLN) | |||
draft-ietf-ccamp-gmpls-mln-reqs-03.txt | draft-ietf-ccamp-gmpls-mln-reqs-04.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any applicable | |||
applicable patent or other IPR claims of which he or she is aware | patent or other IPR claims of which he or she is aware have been or will be | |||
have been or will be disclosed, and any of which he or she becomes | disclosed, and any of which he or she becomes aware will be disclosed, in | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering Task Force | |||
Task Force (IETF), its areas, and its working groups. Note that | (IETF), its areas, and its working groups. Note that other groups may also | |||
other groups may also distribute working documents as Internet- | distribute working documents as Internet-Drafts. | |||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six months and may be | |||
months and may be updated, replaced, or obsoleted by other | updated, replaced, or obsoleted by other documents at any time. It is | |||
documents at any time. It is inappropriate to use Internet-Drafts | inappropriate to use Internet-Drafts as reference material or to cite them other | |||
as reference material or to cite them other than as "work in | than as "work in progress." | |||
progress." | ||||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
This Internet-Draft will expire on April 2007. | This Internet-Draft will expire on Februrary 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
Most of the initial efforts to utilize Generalized MPLS (GMPLS) | Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been | |||
have been related to environments hosting devices with a single | related to environments hosting devices with a single switching capability. The | |||
switching capability. The complexity raised by the control of such | complexity raised by the control of such data planes is similar to that seen in | |||
data planes is similar to that seen in classical IP/MPLS networks. | classical IP/MPLS networks. | |||
By extending MPLS to support multiple switching technologies, GMPLS | By extending 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 either a | |||
layered network of either a single switching technology or multiple | single switching technology or multiple switching technologies. | |||
switching technologies. | ||||
In GMPLS, a switching technology domain defines a region, and a | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
network of multiple switching types is referred to in this document | ||||
as a Multi-Region Network (MRN). When referring in general to a | In GMPLS, a switching technology domain defines a region, and a network of | |||
layered network, which may consist of either a single or multiple | multiple switching types is referred to in this document as a Multi-Region | |||
regions, this document uses the term, Multi-Layer Network (MLN). | Network (MRN). When referring in general to a layered network, which may consist | |||
This document defines a framework for GMPLS based multi- | of either a single or multiple regions, this document uses the term, Multi-Layer | |||
region/multi-layer networks and lists a set of functional | Network (MLN). This document defines a framework for GMPLS based multi- | |||
requirements. | region/multi-layer networks and lists a set of functional requirements. | |||
Table of Contents | Table of Contents | |||
1. Introduction...................................................3 | 1. Introduction.....................................................2 | |||
2. Conventions Used in this Document..............................4 | 2. Conventions Used in this Document....................................4 | |||
2.1. List of acronyms.............................................4 | 2.1. List of acronyms................................................4 | |||
3. Positioning....................................................5 | 3. Positioning......................................................5 | |||
3.1. Data Plane Layers and Control Plane Regions..................5 | 3.1. Data Plane Layers and Control Plane Regions..........................5 | |||
3.2. Service layer networks.......................................6 | 3.2. Service layer networks...........................................6 | |||
3.3. Vertical and Horizontal interaction and integration..........6 | 3.3. Vertical and Horizontal interaction and integration...................6 | |||
4. Key Concepts of GMPLS-Based MLNs and MRNs......................7 | 4. Key Concepts of GMPLS-Based MLNs and MRNs.............................8 | |||
4.1. Interface Switching Capability...............................7 | 4.1. Interface Switching Capability....................................8 | |||
4.2. Multiple Interface Switching Capabilities....................8 | 4.2. Multiple Interface Switching Capabilities...........................8 | |||
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes....9 | 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes..............9 | |||
4.3. Integrated Traffic Engineering (TE) and Resource Control.....9 | 4.3. Integrated Traffic Engineering (TE) and Resource Control..............10 | |||
4.3.1. Triggered Signaling.......................................10 | 4.3.1. Triggered Signaling...........................................10 | |||
4.3.2. FA-LSPs...................................................10 | 4.3.2. FA-LSPs.....................................................11 | |||
4.3.3. Virtual Network Topology (VNT)............................11 | 4.3.3. Virtual Network Topology (VNT)..................................11 | |||
5. Requirements..................................................12 | 5. Requirements....................................................12 | |||
5.1. Handling Single-Switching and Multi-Switching-Type-Capable | 5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes.......12 | |||
Nodes............................................................12 | 5.2. Advertisement of the Available Adaptation Resource...................12 | |||
5.2. Advertisement of the Available Adaptation Resource..........13 | 5.3. Scalability...................................................13 | |||
5.3. Scalability.................................................13 | 5.4. Stability.....................................................13 | |||
5.4. Stability...................................................13 | 5.5. Disruption Minimization.........................................14 | |||
5.5. Disruption Minimization.....................................14 | 5.6. LSP Attribute Inheritance........................................14 | |||
5.6. LSP Attribute Inheritance...................................14 | 5.7. Computing Paths With and Without Nested Signaling....................15 | |||
5.7. Computing Paths With and Without Nested Signaling...........15 | 5.8. LSP Resource Utilization........................................15 | |||
5.8. LSP Resource Utilization....................................16 | 5.8.1. FA-LSP Release and Setup.......................................16 | |||
5.8.1. FA-LSP Release and Setup..................................16 | 5.8.2. Virtual TE-Links.............................................16 | |||
5.8.2. Virtual TE-Links..........................................17 | 5.9. Verification of the LSPs........................................17 | |||
5.9. Verification of the LSPs....................................18 | 6. Security Considerations...........................................18 | |||
6. Security Considerations.......................................18 | 7. IANA Considerations..............................................18 | |||
7. IANA Considerations...........................................19 | 8. References......................................................18 | |||
8. References....................................................19 | 8.1. Normative Reference.............................................18 | |||
8.1. Normative Reference.........................................19 | 8.2. Informative References..........................................18 | |||
8.2. Informative References......................................19 | 9. Authors' Addresses...............................................19 | |||
9. Authors' Addresses............................................20 | 10. Contributors' Addresses..........................................20 | |||
10. Contributors' Addresses......................................21 | 11. Intellectual Property Considerations...............................20 | |||
11. Intellectual Property Considerations.........................21 | 12. Full Copyright Statement.........................................20 | |||
12. Full Copyright Statement.....................................22 | ||||
1. Introduction | ||||
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching | 1. Introduction | |||
technologies: packet switching, layer-2 switching, TDM switching, | ||||
wavelength switching, and fiber switching (see [RFC3945]). The | ||||
Interface Switching Capability (ISC) concept is introduced for | ||||
these switching technologies and is designated as follows: PSC | ||||
(packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | ||||
Division Multiplex capable), LSC (lambda switch capable), and FSC | ||||
(fiber switch capable). | ||||
Service providers may operate networks where multiple different | Generalized MPLS (GMPLS) extends MPLS to handle multiple switching technologies: | |||
switching technologies exist. The representation, in a GMPLS | packet switching, layer-2 switching, TDM switching, wavelength switching, and | |||
control plane, of a switching technology domain is referred to as a | fiber switching (see [RFC3945]). The Interface Switching Capability (ISC) | |||
region [RFC4206]. | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
A switching type describes the ability of a node to forward data of | concept is introduced for these switching technologies and is designated as | |||
a particular data plane technology, and uniquely identifies a | follows: PSC (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | |||
network region. A layer describes a data plane switching | Division Multiplex capable), LSC (lambda switch capable), and FSC (fiber switch | |||
granularity level (e.g., VC4, VC-12). A data plane layer is | capable). | |||
associated with a region in the control plane (e.g., VC4 is | ||||
associated with TDM, MPLS is associated with PSC). However, more | ||||
than one data plane layer can be associated with the same region | ||||
(e.g., both VC4 and VC12 are associated with TDM). Thus, a control | ||||
plane region, identified by its switching type value (e.g., TDM), | ||||
can be sub-divided into smaller granularity component networks | ||||
based on "data plane switching layers". The Interface Switching | ||||
Capability Descriptor (ISCD) [RFC4202], identifying the interface | ||||
switching capability (ISC), the encoding type, and the switching | ||||
bandwidth granularity, enables the characterization of the | ||||
associated layers. | ||||
A network comprising nodes with multiple data plane layers of | The representation, in a GMPLS control plane, of a switching technology domain | |||
either the same ISC or different ISCs, controlled by a single GMPLS | is referred to as a region [RFC4206]. A switching type describes the ability of | |||
control plane instance is called a Multi-Layer Network (MLN). To | a node to forward data of a particular data plane technology, and uniquely | |||
differentiate a network supporting LSPs of different switching | identifies a network region. A layer describes a data plane switching | |||
types from a single region network, a network supporting more than | granularity level (e.g., VC4, VC-12). A data plane layer is associated with a | |||
one switching technology and controlled by a single GMPLS control | region in the control plane (e.g., VC4 is associated with TDM, MPLS is | |||
plane instance is called a Multi-Region Network (MRN). | associated with PSC). However, more than one data plane layer can be associated | |||
with the same region (e.g., both VC4 and VC12 are associated with TDM). Thus, a | ||||
control plane region, identified by its switching type value (e.g., TDM), can be | ||||
sub-divided into smaller granularity component networks based on "data plane | ||||
switching layers". The Interface Switching Capability Descriptor (ISCD) | ||||
[RFC4202], identifying the interface switching capability (ISC), the encoding | ||||
type, and the switching bandwidth granularity, enables the characterization of | ||||
the associated layers. | ||||
MLNs can be categorized according to the distribution of the ISCs | In this document, we define a Multi Layer Network (MLN) to be a TE domain | |||
among the LSRs: | comprising multiple data plane switching layers either of the same ISC (e.g. | |||
- Each LSR may support just one ISC. Such LSRs are known as | TDM) or different ISC (e.g. TDM and PSC) and controlled by a single GMPLS | |||
single-switching-type-capable LSRs. The MLN may comprise a set of | control plane instance. We further define a particular case of MLNs. A Multi | |||
single-switching-type-capable LSRs that support different ISCs. | Region Network (MRN) is defined as a TE domain supporting at least two different | |||
switching technologies (e.g. PSC + TDM) hosted on the same device (referred to | ||||
as multi-switching-type-capable LSRs, see below) and under the control of a | ||||
single GMPLS control plane instance. | ||||
MLNs can be further categorized according to the distribution of the ISCs among | ||||
the LSRs: | ||||
- Each LSR may support just one ISC. | ||||
Such LSRs are known as single-switching-type-capable LSRs. | ||||
The MLN may comprise a set of single-switching-type-capable LSRs | ||||
that 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 be further classified as either "simplex" or "hybrid" nodes | can be further classified as either ‘‘simplex’’ or hybrid’’ nodes | |||
as defined in Section 4.2. | as 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- | |||
switching-type-capable LSRs and multi-switching-type-capable | 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 | |||
different switching capabilities, a single GMPLS instance may be | switching capabilities, a single GMPLS instance controlling the MLN/MRN enables | |||
used to control the MLN enabling rapid service provisioning and | rapid service provisioning and efficient traffic engineering across all | |||
efficient traffic engineering across all switching capabilities. In | switching 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 the | |||
Engineering Database (TED). Since this TED contains the information | information relative to all the different regions and layers existing in the | |||
relative to all the different regions and layers existing in the | network, a path across multiple regions or layers can be computed using this TED. | |||
network, a path across multiple regions or layers can be computed | Thus optimization of network resources can be achieved across the whole MLN/MRN. | |||
using this TED. Thus optimization of network resources can be | ||||
achieved across the whole MLN. | ||||
Consider, for example, a MRN consisting of packet-switch capable | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
routers and TDM cross-connects. Assume that a packet LSP is routed | ||||
between source and destination packet-switch capable routers, and | ||||
that the LSP can be routed across the PSC-region (i.e., utilizing | ||||
only resources of the packet region topology). If the performance | ||||
objective for the LSP is not satisfied, new TE links may be created | ||||
between the packet-switch capable routers across the TDM-region | ||||
(for example, VC-12 links) and the LSP can be routed over those TE | ||||
links. Further, even if the LSP can be successfully established | ||||
across the PSC-region, TDM hierarchical LSPs across the TDM region | ||||
between the packet-switch capable routers may be established and | ||||
used if doing so is necessary to meet the operator's objectives for | ||||
network resources availability (e.g., link bandwidth, or adaptation | ||||
ports between regions) across the regions. The same considerations | ||||
hold when VC4 LSPs are provisioned to provide extra flexibility for | ||||
the VC12 and/or VC11 layers in an MLN. | ||||
This document describes the requirements to support multi- | Consider, for example, a MRN consisting of packet-switch capable routers and TDM | |||
region/multi-layer networks. There is no intention to specify | cross-connects. Assume that a packet LSP is routed between source and | |||
solution-specific elements in this document. The applicability of | destination packet-switch capable routers, and that the LSP can be routed across | |||
existing GMPLS protocols and any protocol extensions to the MRN/MLN | the PSC-region (i.e., utilizing only resources of the packet region topology). | |||
is addressed in separate documents [MRN-EVAL]. | If the performance objective for the packet LSP is not satisfied, new TE links | |||
may be created between the packet-switch capable routers across the TDM-region | ||||
(for example, VC-12 links) and the LSP can be routed over those TE links. | ||||
Further, even if the LSP can be successfully established across the PSC-region, | ||||
TDM hierarchical LSPs across the TDM region between the packet-switch capable | ||||
routers may be established and used if doing so is necessary to meet the | ||||
operator's objectives for network resources availability (e.g., link bandwidth, | ||||
or adaptation ports between regions) across the regions. The same considerations | ||||
hold when VC4 LSPs are provisioned to provide extra flexibility for the VC12 | ||||
and/or VC11 layers in an MLN. | ||||
1.1 Scope | ||||
This document describes the requirements to support multi-region/multi-layer | ||||
networks. There is no intention to specify solution-specific and/or protocol | ||||
elements in this document. The applicability of existing GMPLS protocols and any | ||||
protocol extensions to the MRN/MLN is addressed in separate documents [MRN-EVAL]. | ||||
This document covers the elements of a single GMPLS control plane instance | ||||
controlling multiple layers within a given TE domain. A control plane instance | ||||
can serve one, two or more layers. Other possible approaches such as having | ||||
multiple control plane instances serving disjoint sets of layers are outside the | ||||
scope of this document. | ||||
For such TE domain to interoperate with edge nodes/domains supporting interfaces | ||||
by other SDOs e.g. ITU-T and OIF, an interworking function may be needed. | ||||
Location and specification of this function are outside the scope of this | ||||
document (because interworking aspects are strictly under the responsibility of | ||||
the interworking function.) | ||||
This document assumes that the interconnection of adjacent MRN/MLN TE domains | ||||
makes use of [RFC4726] when their edges also support inter-domain GMPLS RSVP-TE | ||||
extensions. | ||||
2. Conventions Used in this Document | 2. Conventions Used in this Document | |||
Although this is not a protocol specifcation, the key words "MUST", | Although this is not a protocol specification, the key words "MUST", "MUST NOT", | |||
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD | "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | |||
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in this | and "OPTIONAL" are used in this document to highlight requirements, and are to | |||
document to highlight requirements, and are to be interpreted as | be interpreted as described in RFC 2119 [RFC2119]. | |||
described in RFC 2119 [RFC2119]. | ||||
2.1.List of acronyms | 2.1.List of acronyms | |||
MLN: Multi-Layer Network | MLN: Multi-Layer Network | |||
MRN: Multi-Region Network | MRN: Multi-Region Network | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
ISC: Interface Switching Capability | ISC: Interface Switching Capability | |||
ISCD: Interface Switching Capability Descriptor | ISCD: Interface Switching Capability Descriptor | |||
PSC: Packet Switching Capable | PSC: Packet Switching Capable | |||
L2SC: Layer-2 Switching Capable | L2SC: Layer-2 Switching Capable | |||
TDM: Time-Division Switch Capable | TDM: Time-Division Switch Capable | |||
LSC: Lambda Switching Capable | LSC: Lambda Switching Capable | |||
FSC: Fiber Switching Capable | FSC: Fiber Switching Capable | |||
SRLG: Shared Risk Ling Group | SRLG: Shared Risk Ling Group | |||
VNT: Virtual Network Topology | VNT: Virtual Network Topology | |||
FA: Forwarding Adjacency | FA: Forwarding Adjacency | |||
FA-LSP: Forwarding Adjacency Label Switched Path | FA-LSP: Forwarding Adjacency Label Switched Path | |||
TE: Traffic Engineering | TE: Traffic Engineering | |||
TED: Traffic Engineering Database | TED: Traffic Engineering Database | |||
LSP: Label Switched Path | LSP: Label Switched Path | |||
LSR: Label Switching Router | LSR: Label Switching Router | |||
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 | |||
since the network devices on region boundaries bring together | network devices on region boundaries bring together different ISCs. A MLN, | |||
different ISCs. A MLN, however, is not necessarily a MRN since | however, is not necessarily a MRN since multiple layers could be fully contained | |||
multiple layers could be fully contained within a single region. | within a single region. For example, VC12, VC4, and VC4-4c are different layers | |||
For example, VC12, VC4, and VC4-4c are different layers of the TDM | 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 | |||
terminating and/or switching data traffic of a particular | and/or switching data traffic of a particular format [RFC4397]. These resources | |||
format[RFC4397]. These resources can be used for establishing LSPs | can be used for establishing LSPs for traffic delivery. For example, VC-11 and | |||
for traffic delivery. For example, VC-11 and VC4-64c represent two | 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 | |||
of one or more data plane layers that share the same type of | more data plane layers that share the same type of switching technology, that is, | |||
switching technology, that is, the same switching type. For example, | the same switching type. For example, VC-11, VC-4, and VC-4-7v layers are part | |||
VC-11 and VC-4 layers are part of the same TDM region. The regions | of the same TDM region. The regions that are currently defined are: PSC, L2SC, | |||
that are currently defined are: PSC, L2SC, TDM, LSC, and FSC. Hence, | TDM, LSC, and FSC. Hence, an LSP region is a technology domain (identified by | |||
an LSP region is a technology domain (identified by the ISC type) | the ISC type) for which data plane resources (i.e., data links) are represented | |||
for which data plane resources (i.e., data links) are represented | into the control plane as an aggregate of TE information associated with a set | |||
into the control plane as an aggregate of TE information associated | of links (i.e., TE links). For example VC-11 and VC4-64c capable TE links are | |||
with a set of links (i.e., TE links). For example VC-11 and VC4-64c | part of the same TDM region. Multiple layers can thus exist in a single region | |||
capable TE links are part of the same TDM region. Multiple layers | network. | |||
can thus exist in a single region network. | ||||
Note also that the region may produce a distinction within the control plane. | ||||
Layers of the same region share the same switching technology and, therefore, | ||||
use the same set of technology-specific signaling objects and technology- | ||||
specific value setting of TE link attributes within the control plane, but | ||||
layers from different regions may use different technology-specific objects and | ||||
TE attribute values. This means that it may not be possible to simply forward | ||||
the signaling message between LSR hosting different switching technologies | ||||
because change in some of the signaling objects (for example, the traffic | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
parameters) when crossing a region boundary even if a single control plane | ||||
instance is used to manage the whole MRN. We may solve the issue by using | ||||
triggered signaling (See 4.3.1). | ||||
Note also that the region may produce a distinction within the | ||||
control plane. Layers of the same region share the same switching | ||||
technology and, therefore, use the same set of technology-specific | ||||
signaling objects within the control plane, but layers from | ||||
different regions may use different technology-specific objects or | ||||
encodings. This means that there is a control plane discontinuity | ||||
when crossing a region boundary even if a single control plane | ||||
instance is used to manage the whole MRN. | ||||
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 | |||
layers. The customer's network is considered from the provider's | customer's network is considered from the provider's perspective as the highest | |||
perspective as the highest service layer. It interfaces to the | service layer. It interfaces to the highest service layer of the service | |||
highest service layer of the service provider's network. | 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 lower service | |||
provider's network may be provided with support from successively | layers. Service layers are realized via a hierarchy of network layers located | |||
lower service layers. Service layers are realized via a hierarchy | generally in several regions and commonly arranged according to the switching | |||
of network layers located generally in several regions and commonly | 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 | |||
services from the service provider, some Layer 2 (e.g., ATM), while | service provider, some Layer 2 (e.g., ATM), while others purchase Layer 3 | |||
others purchase Layer 3 (IP/MPLS) services. The service provider | (IP/MPLS) services. The service provider realizes the services by a stack of | |||
realizes the services by a stack of network layers located within | network layers located within one or more network regions. The network layers | |||
one or more network regions. The network layers are commonly | are commonly arranged according to the switching capabilities of the devices in | |||
arranged according to the switching capabilities of the devices in | the networks. Thus, a customer network may be provided on top of the GMPLS-based | |||
the networks. Thus, a customer network may be provided on top of | multi-region/multi-layer network. For example, a Layer 1 service (realized via | |||
the GMPLS-based multi-region/multi-layer network. For example, a | the network layers of TDM, and/or LSC, and/or FSC regions) may support a Layer 2 | |||
Layer 1 service (realized via the network layers of TDM, and/or LSC, | network (realized via ATM VP/VC) which may itself support a Layer 3 network | |||
and/or FSC regions) may support a Layer 2 network (realized via ATM | (IP/MPLS region). The supported data plane relationship is a data plane client- | |||
VP/VC) which may itself support a Layer 3 network (IP/MPLS region). | server relationship where the lower layer provides a service for the higher | |||
The supported data plane relationship is a data plane client-server | layer using the data links realized in the lower layer. | |||
relationship where the lower layer provides 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 | |||
are referred to as "Multi-region/Multi-layer network services". For | to as "Multi-region/Multi-layer network services". For example, legacy IP and | |||
example, legacy IP and IP/MPLS networks can be supported on top of | IP/MPLS networks can be supported on top of multi-region/multi-layer networks. | |||
multi-region/multi-layer networks. It has to be emphasized that | It has to be emphasized that delivery of such diverse services is a strong | |||
delivery of such diverse services is a strong motivator for the | 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 | |||
MRN/MLN which is operated by a service provider. For example, a | is operated by a service provider. For example, a pure IP and/or an IP/MPLS | |||
pure IP and/or an IP/MPLS network can be provided on top of GMPLS- | network can be provided on top of GMPLS-based packet over optical networks | |||
based packet over optical networks [MPLS-GMPLS]. The relationship | [MPLS-GMPLS]. The relationship between the networks is a client/server | |||
between the networks is a client/server relationship and, such | relationship and, such services are referred to as "MRN/MLN services". In this | |||
services are referred to as "MRN/MLN services". In this case, the | case, the customer network may form part of the MRN/MLN, or may be partially | |||
customer network may form part of the MRN/MLN, or may be partially | separated, for example to maintain separate routing information but retain | |||
separated, for example to maintain separate routing information but | common signaling. | |||
retain 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 | ||||
within a network element that is capable of supporting more than | ||||
one layer and of realizing the client/server relationships between | ||||
the layers. Protocol exchanges between two network controllers | ||||
managing different regions or layers are also a vertical | ||||
interaction. Integration of these interactions as part of the | ||||
control plane is referred to as vertical integration. Thus, this | ||||
refers to the collaborative mechanisms within a single control | ||||
plane instance driving multiple network layers. Such a concept is | ||||
useful in order to construct a framework that facilitates efficient | ||||
network resource usage and rapid service provisioning in carrier | ||||
networks that are based on multiple layers, switching technologies, | ||||
or ISCs. | ||||
Horizontal interaction is defined as the protocol exchange between | Vertical interaction is defined as the collaborative mechanisms within a network | |||
network controllers that manage transport nodes within a given | element that is capable of supporting more than one layer or region and of | |||
layer or region (i.e., nodes with the same switching capability). | realizing the client/server relationships between the layers or regions. | |||
For instance, the control plane interaction between two TDM network | Protocol exchanges between two network controllers managing different regions or | |||
elements switching at OC-48 is an example of horizontal interaction. | layers are also a vertical interaction. Integration of these interactions as | |||
GMPLS protocol operations handle horizontal interactions within the | part of the control plane is referred to as vertical integration. Thus, this | |||
same routing area. The case where the interaction takes place | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
across a domain boundary, such as between two routing areas within | ||||
the same network layer, is evaluated as part of the inter-domain | ||||
work [RFC4726], and is referred to as horizontal integration. Thus, | ||||
horizontal integration refers to the collaborative mechanisms | ||||
between network partitions and/or administrative divisions such as | ||||
routing areas or autonomous systems. | ||||
This distinction needs further clarification when administrative | refers to the collaborative mechanisms within a single control plane instance | |||
domains match layer boundaries. Horizontal interaction is extended | driving multiple network layers part of the same region or not. Such a concept | |||
to cover such cases. For example, the collaborative mechanisms in | is useful in order to construct a framework that facilitates efficient network | |||
place between two lambda switching capable areas relate to | resource usage and rapid service provisioning in carrier networks that are based | |||
horizontal integration. On the other hand, the collaborative | on multiple layers, switching technologies, or ISCs. | |||
mechanisms in place in a network that supports IP/MPLS over TDM | ||||
switching could be described as vertical and horizontal integration | Horizontal interaction is defined as the protocol exchange between network | |||
in the case where each network belongs to a separate routing area. | controllers that manage transport nodes within a given layer or region. For | |||
instance, the control plane interaction between two TDM network elements | ||||
switching at OC-48 is an example of horizontal interaction. GMPLS protocol | ||||
operations handle horizontal interactions within the same routing area. The case | ||||
where the interaction takes place across a domain boundary, such as between two | ||||
routing areas within the same network layer, is evaluated as part of the inter- | ||||
domain work [RFC4726], and is referred to as horizontal integration. Thus, | ||||
horizontal integration refers to the collaborative mechanisms between network | ||||
partitions and/or administrative divisions such as routing areas or autonomous | ||||
systems. | ||||
This distinction needs further clarification when administrative domains match | ||||
layer/region boundaries. Horizontal interaction is extended to cover such cases. | ||||
For example, the collaborative mechanisms in place between two lambda switching | ||||
capable areas relate to horizontal integration. On the other hand, the | ||||
collaborative mechanisms in place between a packet switching capable (e.g. | ||||
IP/MPLS) domain over a different time division switching capable (eg VC4 SDH) | ||||
domain is part of the horizontal integration while it can be seen as a first | ||||
step towards vertical integration. | ||||
3.4.Motivation | ||||
The applicability of GMPLS to multiple switching technologies provides the | ||||
unified control management approach for both LSP provisioning and recovery. | ||||
Indeed, one of the main motivations for unifying the capabilities and operations | ||||
GMPLS control plane is the desire to support multi LSP-region [RFC4206] routing | ||||
and Traffic Engineering (TE) capability. For instance, this enables effective | ||||
network resource utilization of both the Packet/Layer2 LSP regions and the Time | ||||
Division Multiplexing (TDM) or Lambda LSP regions in high capacity networks. | ||||
The rationales for GMPLS controlled multi-layer/multi-region networks context | ||||
are summarized here below: | ||||
- The maintenance of multiple instances of the control plane on devices hosting | ||||
more than one switching capability not only increases the complexity of their | ||||
interactions but also increases the total amount of processing individual | ||||
instances would handle. | ||||
- The unification of the addressing spaces helps in avoiding multiple | ||||
identification for the same object (a link for instance or more generally any | ||||
network resource), on the other hand such aggregation does not impact the | ||||
separation between the control and the data plane. | ||||
- By maintaining a single routing protocol instance and a single TE database | ||||
per LSR, a unified control plane model prevents from maintaining a dedicated | ||||
routing topology per layer and therefore does not mandate a full mesh of | ||||
routing adjacencies as it is the case with overlaid control planes. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
- The collaboration between associated control planes (packet/framed data | ||||
planes) and non-associated control planes (SONET/SDH, G.709, etc.) is | ||||
facilitated due to the capability of hooking the associated in-band signaling | ||||
to the IP terminating interfaces of the control plane. | ||||
- Resource management and policies to be applied at the edges of such | ||||
environment is facilitated (less control to management interactions) and more | ||||
scalable (through the use of aggregated information). | ||||
- Multi-region/multi-layer traffic engineering is facilitated as TE-links from | ||||
distinct regions/layers are stored within the same TE 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 of either | |||
layers of either the same ISC or different ISCs, controlled by a | the same ISC or different ISCs, controlled by a single GMPLS control plane | |||
single GMPLS control plane instance, is called a Multi-Layer | instance, is called a Multi-Layer Network (MLN). A sub-set of MLNs consists of | |||
Network (MLN). A sub-set of MLNs consists of networks supporting | networks supporting LSPs of different switching technologies (ISCs). A network | |||
LSPs of different switching technologies (ISCs). A network | supporting more than one switching technology is called a Multi-Region Network | |||
supporting more than one switching technology is called a Multi- | (MRN). | |||
Region Network (MRN). | ||||
4.1. Interface Switching Capability | 4.1. Interface Switching Capability | |||
The Interface Switching Capability (ISC) is introduced in GMPLS to | ||||
support various kinds of switching technology in a unified way | ||||
[RFC4202]. An ISC is identified via a switching type. | ||||
A switching type (also referred to as the switching capability | The Interface Switching Capability (ISC) is introduced in GMPLS to support | |||
type) describes the ability of a node to forward data of a | various kinds of switching technology in a unified way [RFC4202]. An ISC is | |||
particular data plane technology, and uniquely identifies a network | identified via a switching type. | |||
region. The following ISC types (and, hence, regions) are defined: | ||||
PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more | ||||
precisely, each interface connecting a data link to a node) in a | ||||
GMPLS network is associated with an ISC. | ||||
The ISC value is advertised as a part of the Interface Switching | A switching type (also referred to as the switching capability type) describes | |||
Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end | the ability of a node to forward data of a particular data plane technology, and | |||
associated with a particular link interface [RFC4202]. Apart from | uniquely identifies a network region. The following ISC types (and, hence, | |||
the ISC, the ISCD contains information including the encoding type, | regions) are defined: PSC, L2SC, TDM, LSC, and FSC. Each end of a data link | |||
the bandwidth granularity, and the unreserved bandwidth on each of | (more precisely, each interface connecting a data link to a node) in a GMPLS | |||
eight priorities at which LSPs can be established. The ISCD does | network is associated with an ISC. | |||
not "identify" network layers, it uniquely characterizes | ||||
information associated to one or more network layers. | ||||
TE link end advertisements may contain multiple ISCDs. This can be | The ISC value is advertised as a part of the Interface Switching Capability | |||
interpreted as advertising a multi-layer (or multi-switching- | Descriptor (ISCD) attribute (sub-TLV) of a TE link end associated with a | |||
capable) TE link end. That is, the TE link end (and therefore the | particular link interface [RFC4202]. Apart from the ISC, the ISCD contains | |||
TE link) is present in multiple layers. | information including the encoding type, the bandwidth granularity, and the | |||
unreserved bandwidth on each of eight priorities at which LSPs can be | ||||
established. The ISCD does not "identify" network layers, it uniquely | ||||
characterizes information associated to one or more network layers. | ||||
TE link end advertisements may contain multiple ISCDs. This can be interpreted | ||||
as advertising a multi-layer (or multi-switching-capable) TE link end. That is, | ||||
the TE link end (and therefore the TE 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- | |||
multi-switching-type-capable nodes. Single-switching-type-capable | switching-type-capable nodes. Single-switching-type-capable nodes advertise the | |||
nodes advertise the same ISC value as part of their ISCD sub-TLV(s) | same ISC value as part of their ISCD sub-TLV(s) to describe the termination | |||
to describe the termination capabilities of each of their TE | capabilities of each of their TE Link(s). This case is described in [RFC4202]. | |||
Link(s). This case is described in [RFC4202]. | ||||
Multi-switching-type-capable LSRs are classified as "simplex" or | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
"hybrid" nodes. Simplex and hybrid nodes are categorized according | ||||
to the way they advertise these multiple ISCs: | ||||
- A simplex node can terminate data links with different switching | Multi-switching-type-capable LSRs are classified as "simplex" or "hybrid" nodes. | |||
capabilities where each data link is connected to the node by a | Simplex and hybrid nodes are categorized according to the way they advertise | |||
separate link interface. So, it advertises several TE Links each | these multiple ISCs: | |||
with a single ISC value carried in its ISCD sub-TLV. For example, | ||||
an LSR with PSC and TDM links each of which is connected to the LSR | ||||
via a separate interface. | ||||
- A hybrid node can terminate data links with different switching | - A simplex node can terminate data links with different switching capabilities | |||
capabilities where the data links are connected to the node by the | where each data link is connected to the node by a separate link interface. | |||
same interface. So, it advertises a single TE Link containing more | So, it advertises several TE Links each with a single ISC value carried in | |||
than one ISCD each with a different ISC value. For example, a node | its ISCD sub-TLV. For example, an LSR with PSC and TDM links each of which is | |||
may terminate PSC and TDM data links and interconnect those | connected to the LSR via a separate interface. | |||
external data links via internal links. The external interfaces | ||||
connected to the node have both PSC and TDM capabilities. | ||||
Additionally, TE link advertisements issued by a simplex or a | - A hybrid node can terminate data links with different switching capabilities | |||
hybrid node may need to provide information about the node's | where the data links are connected to the node by the same interface. So, it | |||
internal adaptation capabilities between the switching technologies | advertises a single TE Link containing more than one ISCD each with a | |||
supported. That is, the node's capability to perform layer border | different ISC value. For example, a node may terminate PSC and TDM data links | |||
node functions. | and interconnect those external data links via internal links. The external | |||
interfaces connected to the node have both PSC and TDM capabilities. | ||||
Additionally, TE link advertisements issued by a simplex or a hybrid node may | ||||
need to provide information about the node's internal adaptation capabilities | ||||
between the switching technologies supported. That is, the node's capability to | ||||
perform layer border node functions. | ||||
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 simplex | |||
more simplex nodes, and a set of single-switching-type-capable | 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 | |||
switching elements (matrices), which support, for instance, TDM and | elements (matrices), which support, for instance, TDM and PSC switching | |||
PSC switching respectively. The node terminates a PSC and a TDM | respectively. The node terminates a PSC and a TDM link (Link1 and Link2 | |||
link (Link1 and Link2 respectively). It also has an internal link | respectively). It also has an internal link connecting the two switching | |||
connecting the two switching elements. | elements. | |||
The two switching elements are internally interconnected in such a | The two switching elements are internally interconnected in such a way that it | |||
way that it is possible to terminate some of the resources of, say, | is possible to terminate some of the resources of, say, Link2 and provide | |||
Link2 and provide adaptation for PSC traffic received/sent over the | adaptation for PSC traffic received/sent over the PSC interface (#b). This | |||
PSC interface (#b). This situation is modeled in GMPLS by | situation is modeled in GMPLS by connecting the local end of Link2 to the TDM | |||
connecting the local end of Link2 to the TDM switching element via | switching element via an additional interface realizing the | |||
an additional interface realizing the termination/adaptation | termination/adaptation function. There are two possible ways to set up PSC LSPs | |||
function. There are two possible ways to set up PSC LSPs through | through the hybrid node. Available resource advertisement (i.e., Unreserved and | |||
the hybrid node. Available resource advertisement (i.e., Unreserved | Min/Max LSP Bandwidth) should cover both of these methods. | |||
and Min/Max LSP Bandwidth) should cover both of these methods. | ||||
Network element | Network element | |||
............................. | ............................. | |||
: -------- : | : -------- : | |||
: | PSC | : | : | PSC | : | |||
Link1 -------------<->--|#a | : | Link1 -------------<->--|#a | : | |||
: +--<->---|#b | : | : +--<->---|#b | : | |||
: | -------- : | : | -------- : | |||
TDM : | ---------- : | TDM : | ---------- : | |||
+PSC : +--<->--|#c TDM | : | +PSC : +--<->--|#c TDM | : | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
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 | ||||
consolidated into a single Traffic Engineering Database (TED) for | ||||
use by the single control plane instance. Since this TED contains | ||||
the information relative to all the layers of all regions in the | ||||
network, a path across multiple layers (possibly crossing multiple | ||||
regions) can be computed using the information in this TED. Thus, | ||||
optimization of network resources across the multiple layers of the | ||||
same region and across multiple regions can be achieved. | ||||
These concepts allow for the operation of one network layer over | In GMPLS-based multi-region/multi-layer networks, TE Links may be consolidated | |||
the topology (that is, TE links) provided by other network layers | into a single Traffic Engineering Database (TED) for use by the single control | |||
(for example, the use of a lower layer LSC LSP carrying PSC LSPs). | plane instance. Since this TED contains the information relative to all the | |||
In turn, a greater degree of control and inter-working can be | layers of all regions in the network, a path across multiple layers (possibly | |||
achieved, including (but not limited too): | crossing multiple regions) can be computed using the information in this TED. | |||
Thus, optimization of network resources across the multiple layers of the same | ||||
region and across multiple regions can be achieved. | ||||
These concepts allow for the operation of one network layer over the topology | ||||
(that is, TE links) provided by other network layers (for example, the use of a | ||||
lower layer LSC LSP carrying PSC LSPs). In turn, a greater degree of control and | ||||
inter-working can be achieved, including (but not limited too): | ||||
- Dynamic establishment of Forwarding Adjacency (FA) LSPs | - Dynamic establishment of Forwarding Adjacency (FA) LSPs | |||
[RFC4206] (see Sections 4.3.2 and 4.3.3). | [RFC4206] (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-switching- | |||
multi-switching-type-capable nodes, an explicit route used to | type-capable nodes, an explicit route used to establish an end-to-end LSP can | |||
establish an end-to-end LSP can specify nodes that belong to | specify nodes that belong to different layers or regions. In this case, a | |||
different layers or regions. In this case, a mechanism to control | mechanism to control the dynamic creation of FA LSPs may be required (see | |||
the dynamic creation of FA LSPs may be required (see Sections 4.3.2 | 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 | |||
dynamically established. The process can be subject to the control | established. The process can be subject to the control of a policy, which may be | |||
of a policy, which may be set by a management component, and which | set by a management component, and which may require that the management plane | |||
may require that the management plane is consulted at the time that | is consulted at the time that the FA LSP is established. Alternatively, the FA | |||
the FA LSP is established. Alternatively, the FA LSP can be | LSP can be established at the request of the control plane without any | |||
established 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 | |||
may be nested into a lower layer FA LSP that crosses the lower | nested into a lower layer FA LSP that crosses the lower layer. From a signaling | |||
layer. From a signaling perspective, there are two alternatives to | perspective, there are two alternatives to establish the lower layer FA LSP: | |||
establish the lower layer FA LSP: static (pre-provisioned) and | static (pre-provisioned) and dynamic (triggered). A pre-provisioned FA-LSP may | |||
dynamic (triggered). A pre-provisioned FA-LSP may be initiated | be initiated either by the operator or automatically using features like TE | |||
either by the operator or automatically using features like TE | auto-mesh [AUTO-MESH]. If such a lower layer LSP does not already exist, the LSP | |||
auto-mesh [AUTO-MESH]. If such a lower layer LSP does not already | may be established dynamically. Such a mechanism is referred to as "triggered | |||
exist, the LSP may be established dynamically. Such a mechanism is | signaling". | |||
referred to as "triggered signaling". | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
4.3.2. FA-LSPs | 4.3.2. FA-LSPs | |||
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. | ||||
Furthermore, it can be advertised as a TE-link, allowing other | Once an LSP is created across a layer from one layer border node to another, it | |||
nodes to consider the LSP as a TE link for their path computation | can be used as a data link in an upper layer. | |||
[RFC4206]. An LSP created either statically or dynamically by one | ||||
instance of the control plane and advertised as a TE link into the | ||||
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 | ||||
link is called a Forwarding Adjacency (FA). An FA has the special | ||||
characteristic of not requiring a routing adjacency (peering) | ||||
between its end points yet still guaranteeing control plane | ||||
connectivity between the FA-LSP end points based on a signaling | ||||
adjacency. An FA is a useful and powerful tool for improving the | ||||
scalability of GMPLS Traffic Engineering (TE) capable networks | ||||
since multiple higher layer LSPs may be nested (aggregated) over a | ||||
single FA-LSP. | ||||
The aggregation of LSPs enables the creation of a vertical (nested) | Furthermore, it can be advertised as a TE-link, allowing other nodes to consider | |||
LSP Hierarchy. A set of FA-LSPs across or within a lower layer can | the LSP as a TE link for their path computation [RFC4206]. An LSP created either | |||
be used during path selection by a higher layer LSP. Likewise, the | statically or dynamically by one instance of the control plane and advertised as | |||
higher layer LSPs may be carried over dynamic data links realized | a TE link into the same instance of the control plane is called a Forwarding | |||
via LSPs (just as they are carried over any "regular" static data | Adjacency LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE link | |||
links). This process requires the nesting of LSPs through a | is called a Forwarding Adjacency (FA). An FA has the special characteristic of | |||
hierarchical process [RFC4206]. The TED contains a set of LSP | not requiring a routing adjacency (peering) between its end points yet still | |||
advertisements from different layers that are identified by the | guaranteeing control plane connectivity between the FA-LSP end points based on a | |||
ISCD contained within the TE link advertisement associated with the | signaling adjacency. An FA is a useful and powerful tool for improving the | |||
LSP [RFC4202]. | scalability of GMPLS Traffic Engineering (TE) capable networks since multiple | |||
higher layer LSPs may be nested (aggregated) over a single FA-LSP. | ||||
If a lower layer LSP is not advertised as an FA, it can still be | The aggregation of LSPs enables the creation of a vertical (nested) LSP | |||
used to carry higher layer LSPs across the lower layer. For example, | Hierarchy. A set of FA-LSPs across or within a lower layer can be used during | |||
if the LSP is set up using triggered signaling, it will be used to | path selection by a higher layer LSP. Likewise, the higher layer LSPs may be | |||
carry the higher layer LSP that caused the trigger. Further, the | carried over dynamic data links realized via LSPs (just as they are carried over | |||
lower layer remains available for use by other higher layer LSPs | any "regular" static data links). This process requires the nesting of LSPs | |||
arriving at the boundary. | through a hierarchical process [RFC4206]. The TED contains a set of LSP | |||
advertisements from different layers that are identified by the ISCD contained | ||||
within the TE link advertisement associated with the LSP [RFC4202]. | ||||
Under some circumstances it may be useful to control the | If a lower layer LSP is not advertised as an FA, it can still be used to carry | |||
advertisement of LSPs as FAs during the signaling establishment of | higher layer LSPs across the lower layer. For example, if the LSP is set up | |||
the LSPs [DYN-HIER]. | using triggered signaling, it will be used to carry the higher layer LSP that | |||
caused the trigger. Further, the lower layer remains available for use by other | ||||
higher layer LSPs arriving at the boundary. | ||||
Under some circumstances it may be useful to control the advertisement of LSPs | ||||
as FAs during the signaling establishment of 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 of lower-layer LSPs provides information for efficient path | |||
efficient path handling in upper-layer(s) of the MLN, or, in other | handling in upper-layer(s) of the MLN, or, in other words, provides a virtual | |||
words, provides a virtual network topology (VNT) to the upper- | network topology (VNT) to the upper-layers. For instance, a set of LSPs, each of | |||
layers. For instance, a set of LSPs, each of which is supported by | which is supported by an LSC LSP, provides a virtual network topology to the | |||
an LSC LSP, provides a virtual network topology to the layers of a | layers of a PSC region, assuming that the PSC region is connected to the LSC | |||
PSC region, assuming that the PSC region is connected to the LSC | region. Note that a single lower-layer LSP is a special case of the VNT. The | |||
region. Note that a single lower-layer LSP is a special case of the | virtual network topology is configured by setting up or tearing down the lower | |||
VNT. The virtual network topology is configured by setting up or | layer LSPs. By using GMPLS signaling and routing protocols, the virtual network | |||
tearing down the lower layer LSPs. By using GMPLS signaling and | topology can be adapted to traffic demands. | |||
routing protocols, the virtual network topology can be adapted to | ||||
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 | |||
diversely-routed lower-layer LSPs are used or not, the routes of | lower-layer LSPs are used or not, the routes of lower-layer LSPs are hidden from | |||
lower-layer LSPs are hidden from the upper layer in the VNT. Thus, | the upper layer in the VNT. Thus, the VNT simplifies the upper-layer routing and | |||
the VNT simplifies the upper-layer routing and traffic engineering | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
decisions by hiding the routes taken by the lower-layer LSPs. | ||||
However hiding the routes of the lower-layer LSPs may lose | ||||
important information that is needed to make the higher-layer LSPs | ||||
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 | traffic engineering decisions by hiding the routes taken by the lower-layer LSPs. | |||
traffic demand changes, topology configuration changes, signaling | However hiding the routes of the lower-layer LSPs may lose important information | |||
requests from the upper layer, and network failures. For instance, | that is needed to make the higher-layer LSPs reliable. For instance, the routing | |||
by reconfiguring the virtual network topology according to the | and traffic engineering in the IP/MPLS layer does not usually consider how the | |||
traffic demand between source and destination node pairs, network | IP/MPLS TE links are formed from optical paths that are routed in the fiber | |||
performance factors, such as maximum link utilization and residual | layer. Two optical paths may share the same fiber link in the lower-layer and | |||
capacity of the network, can be optimized. Reconfiguration is | therefore they may both fail if the fiber link is cut. Thus the shared risk | |||
performed by computing the new VNT from the traffic demand matrix | properties of the TE links in the VNT must be made available to the higher layer | |||
and optionally from the current VNT. Exact details are outside the | during path computation. Further, the topology of the VNT should be designed so | |||
scope of this document. However, this method may be tailored | that any single fiber cut does not bisect the VNT. These issues are addressed | |||
according to the service provider's policy regarding network | later in this document. | |||
performance and quality of service (delay, loss/disruption, | ||||
utilization, residual capacity, reliability). | Reconfiguration of the virtual network topology may be triggered by traffic | |||
demand changes, topology configuration changes, signaling requests from the | ||||
upper layer, and network failures. For instance, by reconfiguring the virtual | ||||
network topology 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- | |||
switching-type-capable nodes. The path computation mechanism in the | type-capable nodes. The path computation mechanism in the MLN SHOULD be able to | |||
MLN SHOULD be able to compute paths consisting of any combination | compute paths consisting of any combination of such nodes. | |||
of such nodes. | ||||
Both single-switching-type-capable and multi-switching-type-capable (simplex or | ||||
hybrid) nodes could play the role of layer boundary. MRN/MLN Path computation | ||||
SHOULD handle TE topologies built of any combination of nodes | ||||
Both single-switching-type-capable and multi-switching-type-capable | ||||
(simplex or hybrid) nodes could play the role of layer boundary. | ||||
MRN/MLN Path computation SHOULD handle TE topologies built of any | ||||
combination of nodes | ||||
5.2. Advertisement of the Available Adaptation Resource | 5.2. Advertisement of the Available Adaptation Resource | |||
A hybrid node SHOULD maintain resources on its internal links (the | A hybrid node SHOULD maintain resources on its internal links (the links | |||
links required for vertical (layer) integration) and SHOULD | required for vertical (layer) integration) and SHOULD advertise the resource | |||
advertise the resource information for those links. Likewise, path | information for those links. Likewise, path computation elements SHOULD be | |||
computation elements SHOULD be prepared to use the availability of | prepared to use the availability of termination/adaptation resources as a | |||
termination/adaptation resources as a constraint in MRN/MLN path | constraint in MRN/MLN path computations to reduce the higher layer LSP setup | |||
computations to reduce the higher layer LSP setup blocking | blocking probability caused by the lack of necessary termination/ adaptation | |||
probability caused by the lack of necessary termination/ adaptation | ||||
resources in the lower layer(s). | resources in the lower layer(s). | |||
The advertisement of the adaptation capability to terminate LSPs of | The advertisement of the adaptation capability to terminate LSPs of lower-region | |||
lower-region and forward traffic in the upper-region is REQUIRED, | and forward traffic in the upper-region is REQUIRED, as it provides critical | |||
as it provides critical information when performing multi-region | information when performing multi-region path computation. | |||
path computation. | ||||
The mechanism SHOULD cover the case where the upper-layer links | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
which are directly connected to upper-layer switching element and | ||||
the ones which are connected through internal links between upper- | The mechanism SHOULD cover the case where the upper-layer links which are | |||
layer element and lower-layer element coexist (See section 4.2.1). | directly connected to upper-layer switching element and the ones which are | |||
connected through internal links between upper-layer element and lower-layer | ||||
element coexist (See section 4.2.1). | ||||
5.3. Scalability | 5.3. Scalability | |||
The MRN/MLN relies on a unified traffic engineering and routing | The MRN/MLN relies on a unified traffic engineering and routing model. | |||
model. The TED in each LSR is populated with TE-links from all | - Unified routing model: by maintaining a single routing protocol instance and | |||
layers of all regions. This may lead to a huge amount of | a single TE database per LSR, a unified control plane model prevents from | |||
maintaining a dedicated routing topology per layer and therefore does not | ||||
mandate a full mesh of routing adjacencies per layer. | ||||
- Unified TE model: the TED in each LSR is populated with TE-links from all | ||||
layers of all regions (TE links interfaces on multiple-switching capability | ||||
LSR can be advertised with multiple ISCD). This may lead to a large amount of | ||||
information that has to be flooded and stored within the network. | information that has to be flooded and stored within the network. | |||
Furthermore, path computation times, which may be of great | ||||
importance during restoration, will depend on the size of the TED. | ||||
Thus MRN/MLN routing mechanisms MUST be designed to scale well with | Furthermore, path computation times, which may be of great importance during | |||
an increase of any of the following: | restoration, will depend on the size of the TED. | |||
Thus MRN/MLN routing mechanisms MUST be designed to scale well with 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 LSPs | |||
- Number of regions and layers | - Number of regions and layers | |||
- Number of ISCDs per TE-link. | - 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 | |||
information filtering based on ISCDs. The path computation | filtering based on ISCDs. The path computation mechanism and the signaling | |||
mechanism and the signaling protocol SHOULD be able to operate on | protocol SHOULD be able to operate on partial TE information. | |||
partial TE information. | ||||
Since TE Links can advertise multiple Interface Switching Capabilities (ISC), | ||||
the number of links can be limited (by combination) by using specific | ||||
topological maps referred to as VNT (Virtual Network Topologies). The | ||||
introduction of virtual topological maps leads us to consider the concept of | ||||
emulation of 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 link state. | |||
associated link state. The path computation stability of an upper | The path computation stability of an upper layer may be impaired if the VNT | |||
layer may be impaired if the VNT changes frequently and/or if the | changes frequently and/or if the status and TE parameters (the TE metric, for | |||
status and TE parameters (the TE metric, for instance) of links in | instance) of links in the VNT changes frequently. In this context, robustness of | |||
the VNT changes frequently. | the VNT is defined as the capability to smooth changes that may occur and avoid | |||
their propagation into higher layers. Changes to the VNT may be caused by the | ||||
creation, deletion, or modification of LSPs. | ||||
In this context, robustness of the VNT is defined as the capability | Creation, deletion, and modification of LSPs MAY be triggered by adjacent layers | |||
to smooth changes that may occur and avoid their propagation into | or through operational actions to meet traffic demand changes, topology changes, | |||
higher layers. Changes to the VNT may be caused by the creation, | signaling requests from the upper layer, and network failures. Routing | |||
deletion, or modification of LSPs. | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
Creation, deletion, and modification of LSPs MAY be triggered by | robustness SHOULD be traded with adaptability with respect to the change of | |||
adjacent layers or through operational actions to meet traffic | incoming traffic requests. | |||
demand changes, topology changes, signaling requests from the upper | ||||
layer, and network failures. Routing robustness SHOULD be traded | ||||
with adaptability with respect to the change of incoming traffic | ||||
requests. | ||||
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- | |||
the upper-layer LSP might be disrupted. Such disruption to the | layer LSP might be disrupted. Such disruption to the upper layers MUST be | |||
upper layers MUST be minimized. | minimized. | |||
When residual resource decreases to a certain level, some lower | When residual resource decreases to a certain level, some lower layer LSPs MAY | |||
layer LSPs MAY be released according to local or network policies. | be released according to local or network policies. There is a trade-off between | |||
There is a trade-off between minimizing the amount of resource | minimizing the amount of resource reserved in the lower layer and disrupting | |||
reserved in the lower layer and disrupting higher layer traffic | higher layer traffic (i.e. moving the traffic to other TE-LSPs so that some LSPs | |||
(i.e. moving the traffic to other TE-LSPs so that some LSPs can be | can be released). Such traffic disruption MAY be allowed, but MUST be under the | |||
released). Such traffic disruption MAY be allowed, but MUST be | control of policy that can be configured by the operator. Any repositioning of | |||
under the control of policy that can be configured by the operator. | traffic MUST be as non-disruptive as possible (for example, using make-before- | |||
Any repositioning of traffic MUST be as non-disruptive as possible | break). | |||
(for example, using 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 that | |||
LSP that provides the TE-link, and so from the TE-links in the | provides the TE-link, and so from the TE-links in the lower layer that are | |||
lower layer that are traversed by the LSP. | 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 | |||
Particular attention should be given to the inheritance of TE | attention should be given to the inheritance of TE metric (which may be other | |||
metric (which may be other than a strict sum of the metrics of the | than a strict sum of the metrics of the component TE links at the lower layer), | |||
component TE links at the lower layer), protection attributes, and | 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 | |||
lose important information necessary to make LSPs in the higher | important information necessary to make LSPs in the higher layer network | |||
layer network reliable. SRLGs may be used to identify which lower- | reliable. SRLGs may be used to identify which lower-layer LSPs share the same | |||
layer LSPs share the same failure risk so that the potential risk | failure risk so that the potential risk of the VNT becoming disjoint can be | |||
of the VNT becoming disjoint can be minimized, and so that resource | minimized, and so that resource disjoint protection paths can be set up in the | |||
disjoint protection paths can be set up in the higher layer. How to | higher layer. How to inherit the SRLG information from the lower layer to the | |||
inherit the SRLG information from the lower layer to the upper | upper layer needs more discussion and is out of scope of this document. | |||
layer needs more discussion and is out of scope of this document. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
5.7.Computing Paths With and Without Nested Signaling | 5.7.Computing Paths With and Without Nested Signaling | |||
Path computation MAY take into account LSP region and layer | Path computation MAY take into account LSP region and layer boundaries when | |||
boundaries when computing a path for an LSP. For example, path | computing a path for an LSP. For example, path computation MAY restrict the path | |||
computation MAY restrict the path taken by an LSP to only the links | taken by an LSP to only the links whose interface switching capability is PSC. | |||
whose interface switching capability is PSC. | ||||
Interface switching capability is used as a constraint in path | Interface switching capability is used as a constraint in path computation. For | |||
computation. For example, a TDM-LSP is routed over the topology | example, a TDM-LSP is routed over the topology composed of TE links of the same | |||
composed of TE links of the same TDM layer. In calculating the path | TDM layer. In calculating the path for the LSP, the TED MAY be filtered to | |||
for the LSP, the TED MAY be filtered to include only links where | include only links where both end include requested LSP switching type. In this | |||
both end include requested LSP switching type. In this way | way hierarchical routing is done by using a TED filtered with respect to | |||
hierarchical routing is done by using a TED filtered with respect | switching capability (that is, with respect to particular layer). | |||
to switching capability (that is, with respect to particular layer). | ||||
If triggered signaling is allowed, the path computation mechanism | If triggered signaling is allowed, the path computation mechanism MAY produce a | |||
MAY produce a route containing multiple layers/regions. The path is | route containing multiple layers/regions. The path is computed over the multiple | |||
computed over the multiple layers/regions even if the path is not | layers/regions even if the path is not "connected" in the same layer as the | |||
"connected" in the same layer as the endpoints of the path exist. | endpoints of the path exist. Note that here we assume that triggered signaling | |||
Note that here we assume that triggered signaling will be invoked | will be invoked to make the path "connected", when the upper-layer signaling | |||
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 that includes | The upper-layer signaling request may contain an ERO that includes only hops in | |||
only hops in the upper layer, in which case the boundary node is | the upper layer, in which case the boundary node is responsible for triggered | |||
responsible for triggered creation of the lower-layer FA-LSP using | creation of the lower-layer FA-LSP using a path of its choice, or for the | |||
a path of its choice, or for the selection of any available lower | selection of any available lower layer LSP as a data link for the higher layer. | |||
layer LSP as a data link for the higher layer. This mechanism is | This mechanism is appropriate for environments where the TED is filtered in the | |||
appropriate for environments where the TED is filtered in the | higher layer, where separate routing instances are used per layer, or where | |||
higher layer, where separate routing instances are used per layer, | administrative policies prevent the higher layer from specifying paths through | |||
or where administrative policies prevent the higher layer from | the lower layer. | |||
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 | |||
(virtual or real) into the higher layer, then the higher layer | real) into the higher layer, then the higher layer signaling request may contain | |||
signaling request may contain the TE link identifier and so | the TE link identifier and so indicate the lower layer resources to be used. But | |||
indicate the lower layer resources to be used. But in this case, | in this case, the path of the lower layer LSP can be dynamically changed by the | |||
the path of the lower layer LSP can be dynamically changed by the | ||||
lower layer at any time. | lower layer at any time. | |||
Alternatively, the upper-layer signaling request may contain an ERO | Alternatively, the upper-layer signaling request may contain an ERO specifying | |||
specifying the lower layer FA-LSP route. In this case, the boundary | the lower layer FA-LSP route. In this case, the boundary node is responsible for | |||
node is responsible for decision as to which it should use the path | decision as to which it should use the path contained in the strict ERO or it | |||
contained in the strict ERO or it should re-compute the path within | should re-compute the path within in the lower-layer. | |||
in the lower-layer. | ||||
Even in case the lower-layer FA-LSPs are already established, a | Even in case the lower-layer FA-LSPs are already established, a signaling | |||
signaling request may also be encoded as loose ERO. In this | request may also be encoded as loose ERO. In this situation, it is up to the | |||
situation, it is up to the boundary node to decide whether it | boundary node to decide whether it should a new lower-layer FA-LSP or it should | |||
should a new lower-layer FA-LSP or it should use the existing | use the existing lower-layer FA-LSPs. | |||
lower-layer FA-LSPs. | ||||
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 | |||
upper-layer or an IGP adjacency can be brought up on the lower- | an IGP adjacency can be brought up on the lower-layer FA-LSP. | |||
layer FA-LSP. | ||||
5.8. LSP Resource Utilization | 5.8. LSP Resource Utilization | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
It MUST be possible to utilize network resources efficiently. | It MUST be possible to utilize network resources efficiently. Particularly, | |||
Particularly, resource usage in all layers SHOULD be optimized as a | resource usage in all layers SHOULD be optimized as a whole (i.e., across all | |||
whole (i.e., across all layers), in a coordinated manner, (i.e., | layers), in a coordinated manner, (i.e., taking all layers into account). The | |||
taking all layers into account). The number of lower-layer LSPs | number of lower-layer LSPs carrying upper-layer LSPs SHOULD be minimized (note | |||
carrying upper-layer LSPs SHOULD be minimized (Note that multiple | that multiple LSPs MAY be used for load balancing). Lower-layer LSPs that could | |||
LSPs MAY be used for load balancing). Lower-layer LSPs that could | have their traffic re-routed onto other LSPs are unnecessary and SHOULD be | |||
have their traffic re-routed onto other LSPs are unnecessary and | avoided. | |||
SHOULD be avoided. | ||||
5.8.1. FA-LSP Release and Setup | 5.8.1. FA-LSP Release and Setup | |||
Statistical multiplexing can only be employed in PSC and L2SC | Statistical multiplexing can only be employed in PSC and L2SC regions. A PSC or | |||
regions. A PSC or L2SC LSP may or may not consume the maximum | L2SC LSP may or may not consume the maximum reservable bandwidth of the TE link | |||
reservable bandwidth of the TE link (FA LSP) that carries it. On | (FA LSP) that carries it. On the other hand, a TDM, or LSC LSP always consumes a | |||
the other hand, a TDM, or LSC LSP always consumes a fixed amount of | fixed amount of bandwidth as long as it exists (and is fully instantiated) | |||
bandwidth as long as it exists (and is fully instantiated) because | because statistical multiplexing is not available. | |||
statistical multiplexing is not available. | ||||
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 | |||
higher-layer LSP MAY be released so that lower-layer resources are | LSP MAY be released so that lower-layer resources are released and can be | |||
released and can be assigned to other uses. Note that if a small | assigned to other uses. Note that if a small fraction of the available bandwidth | |||
fraction of the available bandwidth of an FA-LSP is still in use, | of an FA-LSP is still in use, the nested LSPs can also be re-routed to other FA- | |||
the nested LSPs can also be re-routed to other FA-LSPs (optionally | LSPs (optionally using the make-before-break technique) to completely free up | |||
using the make-before-break technique) to completely free up the | the FA-LSP. Alternatively, unused FA LSPs MAY be retained for future use. | |||
FA-LSP. Alternatively, unused FA LSPs MAY be retained for future | Release or retention of underutilized FA LSPs is a policy decision. | |||
use. Release or retention of underutilized FA LSPs is a policy | ||||
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 | |||
rerouting of an FA LSP while keeping interface identifiers of | FA LSP while keeping interface identifiers of corresponding TE links unchanged. | |||
corresponding TE links unchanged. Further, this process MUST be | Further, this process MUST be possible while the FA LSP is carrying traffic | |||
possible while the FA LSP is carrying traffic (higher layer LSPs) | (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 | |||
consider residual resources and the change of traffic demand across | residual resources and the change of traffic demand across the region. By | |||
the region. By creating the new FA LSPs, the network performance | creating the new FA LSPs, the network performance such as maximum residual | |||
such as maximum residual capacity may increase. | capacity may increase. | |||
As the number of FA LSPs grows, the residual resource may decrease. | As the number of FA LSPs grows, the residual resource may decrease. In this case, | |||
In this case, re-optimization of FA LSPs MAY be invoked according | re-optimization of FA LSPs MAY be invoked according to policy. | |||
to policy. | ||||
Any solution MUST include measures to protect against network | Any solution MUST include measures to protect against network destabilization | |||
destabilization caused by the rapid setup and teardown of LSPs as | caused by the rapid setup and teardown of LSPs as traffic demand varies near a | |||
traffic demand varies near a threshold. | threshold. | |||
Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly | Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly advertise | |||
advertise the LSP as a TE link and to coordinate into which routing | the LSP as a TE link and to coordinate into which routing instances the TE link | |||
instances the TE link should be advertised. | 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) | |||
pre-provision) the set of lower layer LSPs that provide the VNT | the set of lower layer LSPs that provide the VNT since this might reserve | |||
since this might reserve bandwidth that could be used for other | bandwidth that could be used for other LSPs in the absence of upper-layer | |||
LSPs in the absence of upper-layer traffic. | traffic. | |||
However, in order to allow path computation of upper-layer LSPs | ||||
across the lower-layer, the lower-layer LSPs MAY be advertised into | ||||
the upper-layer as though they had been fully established, but | ||||
without actually establishing them. Such TE links that represent | ||||
the possibility of an underlying LSP are termed "virtual TE-links." | ||||
It is an implementation choice at a layer boundary node whether to | ||||
create real or virtual TE-links, and the choice if available in an | ||||
implementation MUST be under the control of operator policy. Note | ||||
that there is no requirement to support the creation of virtual TE- | ||||
links, since real TE-links (with established LSPs) may be used, and | ||||
even if there are no TE-links (virtual or real) advertised to the | ||||
higher layer, it is possible to route a higher layer LSP into a | ||||
lower layer on the assumptions that proper hierarchical LSPs in the | ||||
lower layer will be dynamically created (triggered) as needed. | ||||
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. | ||||
If virtual TE-Links are used in place of pre-established LSPs, the | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
TE-links across the upper-layer can remain stable using pre- | ||||
computed paths while wastage of bandwidth within the lower-layer | ||||
and unnecessary reservation of adaptation ports at the border nodes | ||||
can be avoided. | ||||
The concept of the VNT can be extended to allow the virtual TE- | However, in order to allow path computation of upper-layer LSPs across the | |||
links to form part of the VNT. The combination of the fully | lower-layer, the lower-layer LSPs MAY be advertised into the upper-layer as | |||
provisioned TE-links and the virtual TE-links defines the VNT | though they had been fully established, but without actually establishing them. | |||
provided by the lower layer. | Such TE links that represent the possibility of an underlying LSP are termed | |||
"virtual TE-links." It is an implementation choice at a layer boundary node | ||||
whether to create real or virtual TE-links, and the choice if available in an | ||||
implementation MUST be under the control of operator policy. Note that there is | ||||
no requirement to support the creation of virtual TE-links, since real TE-links | ||||
(with established LSPs) may be used, and even if there are no TE-links (virtual | ||||
or real) advertised to the higher layer, it is possible to route a higher layer | ||||
LSP into a lower layer on the assumptions that proper hierarchical LSPs in the | ||||
lower layer will be dynamically created (triggered) as needed. | ||||
The solution SHOULD provide operations to facilitate the build-up | If an upper-layer LSP that makes use of a virtual TE-Link is set up, the | |||
of such virtual TE-links, taking into account the (forecast) | underlying LSP MUST be immediately signaled in the lower layer. | |||
traffic demand and available resource in the lower-layer. | ||||
Virtual TE-links MAY be modified dynamically (by adding or removing | If virtual TE-Links are used in place of pre-established LSPs, the TE-links | |||
virtual TE links, or changing their capacity) according to the | across the upper-layer can remain stable using pre-computed paths while wastage | |||
change of the (forecast) traffic demand and the available resource | of bandwidth within the lower-layer and unnecessary reservation of adaptation | |||
in the lower-layer. | ports at the border nodes can be avoided. | |||
Any solution MUST include measures to protect against network | The solution SHOULD provide operations to facilitate the build-up of such | |||
destabilization caused by the rapid changes in the virtual network | virtual TE-links, taking into account the (forecast) traffic demand and | |||
topology as traffic demand varies near a threshold. | available resource in the lower-layer. | |||
The VNT can be changed by setting up and/or tearing down virtual TE | Virtual TE-links MAY be added, removed or modified dynamically (by changing | |||
links as well as by modifying real links (i.e. the fully | their capacity) according to the change of the (forecast) traffic demand and the | |||
provisioned LSPs). | available resource in the lower-layer. The maximum number of virtual TE links | |||
that can be defined SHOULD be configurable. | ||||
The maximum number of virtual TE links that can be defined SHOULD | Any solution MUST include measures to protect against network destabilization | |||
be configurable. | caused by the rapid changes in the virtual network topology as traffic demand | |||
varies near a threshold. | ||||
How to design the VNT and how to manage it are out of scope of this | The concept of the VNT can be extended to allow the virtual TE-links to form | |||
document. | part of the VNT. The combination of the fully provisioned TE-links and the | |||
virtual TE-links defines the VNT provided by the lower layer. The VNT can be | ||||
changed by setting up and/or tearing down virtual TE links as well as by | ||||
modifying real links (i.e. the fully provisioned LSPs). How to design the VNT | ||||
and how to manage it are out of scope of this document. | ||||
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, | |||
higher layer, the LSP MAY be verified for correct connectivity and | the LSP MAY be verified for correct connectivity and data integrity. Such | |||
data integrity. Such mechanisms are data technology-specific and | mechanisms are data technology-specific and are beyond the scope of this | |||
are beyond the scope of this document, but may be coordinated | document, but may be coordinated through the GMPLS control plane. | |||
through the GMPLS control plane. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
6. Security Considerations | 6. Security Considerations | |||
The current version of this document does not introduce any new | The current version of this document does not introduce any new security | |||
security considerations as it only lists a set of requirements. | considerations as it only lists a set of requirements. | |||
It is expected that solution documents will include a full analysis | It is expected that solution documents will include a full analysis of the | |||
of the security issues that any protocol extensions introduce. | security issues that any protocol extensions introduce. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This informational document makes no requests to IANA for action. | This informational document makes no requests to IANA for action. | |||
8. References | 8. References | |||
8.1. Normative Reference | 8.1. Normative Reference | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Indicate Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
March 1997. | ||||
[RFC4202] K.Kompella and Y.Rekhter, "Routing Extensions in | [RFC4202] K.Kompella and Y.Rekhter, "Routing Extensions in Support of | |||
Support of Generalized Multi-Protocol Label | Generalized Multi-Protocol Label Switching (GMPLS)," RFC4202, | |||
Switching (GMPLS)," RFC4202, October 2005. | October 2005. | |||
[RFC4726] A.Farrel, J-P. Vasseur, and A.Ayyangar, "A Framework | [RFC4726] A.Farrel, J-P. Vasseur, and A.Ayyangar, "A Framework for Inter- | |||
for Inter-Domain Multiprotocol Label Switching | Domain Multiprotocol Label Switching Traffic Engineering", RFC | |||
Traffic Engineering", RFC 4726, November 2006. | 4726, November 2006. | |||
[RFC4206] K.Kompella and Y.Rekhter, "Label Switched Paths (LSP) | [RFC4206] K.Kompella and Y.Rekhter, "Label Switched Paths (LSP) Hierarchy | |||
Hierarchy with Generalized Multi-Protocol Label | with Generalized Multi-Protocol Label Switching (GMPLS) Traffic | |||
Switching (GMPLS) Traffic Engineering (TE)," | Engineering (TE)," RFC4206, Oct. 2005. | |||
RFC4206, Oct. 2005. | ||||
[RFC3945] E.Mannie (Ed.), "Generalized Multi-Protocol Label | [RFC3945] E.Mannie (Ed.), "Generalized Multi-Protocol Label Switching | |||
Switching (GMPLS) Architecture", RFC 3945, October | (GMPLS) Architecture", RFC 3945, October 2004. | |||
2004. | [RFC4397] I.Bryskin and A. Farrel, "A Lexicography for the Interpretation of | |||
[RFC4397] I.Bryskin and A. Farrel, "A Lexicography for the | Generalized Multiprotocol Label Switching (GMPLS) | |||
Interpretation of Generalized Multiprotocol | Terminology within the Context of the ITU-T's Automatically | |||
Label Switching (GMPLS) Terminology within the | Switched Optical Network (ASON) Architecture", RFC 4397, | |||
Context of the ITU-T's Automatically Switched | ||||
Optical Network (ASON) Architecture", RFC 4397, | ||||
February 2006. | February 2006. | |||
8.2. Informative References | 8.2. Informative References | |||
[MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., | [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., Shiomoto, | |||
Shiomoto, K., Vigoureux, M.,"Evaluation of existing | K., Vigoureux, M.,"Evaluation of existing GMPLS Protocols | |||
GMPLS Protocols against Multi Layer and Multi Region | against Multi Layer and Multi Region Networks (MLN/MRN)", | |||
Networks (MLN/MRN)", draft-ietf-ccamp-gmpls-mrn-eval, | draft-ietf-ccamp-gmpls-mrn-eval, work in progress. | |||
work in progress. | ||||
[MPLS-GMPLS] K. Kumaki (Editor), "Interworking Requirements to | draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | |||
Support operation of MPLS-TE over GMPLS networks", | ||||
draft-ietf-ccamp-mpls-gmpls-interwork-reqts, work in | ||||
progress. | ||||
[DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and | [MPLS-GMPLS] K. Kumaki (Editor), "Interworking Requirements to Support | |||
Ali, Z., "Procedures for Dynamically Signaled | operation of MPLS-TE over GMPLS networks", draft- | |||
Hierarchical Label Switched Paths", draft-ietf- | ietf-ccamp-mpls-gmpls-interwork-reqts, work in progress. | |||
ccamp-lsp-hierarchy-bis, work in progress. | ||||
[AUTO-MESH] Vasseur, JP., Le Roux, JL., et al., "Routing | [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and Ali, Z., | |||
extensions for discovery of Multiprotocol (MPLS) | "Procedures for Dynamically Signaled Hierarchical Label | |||
Label Switch Router (LSR) Traffic Engineering (TE) | Switched Paths", draft-ietf-ccamp-lsp-hierarchy-bis, work in | |||
mesh membership", draft-ietf-ccamp-automesh, work in | ||||
progress. | progress. | |||
[AUTO-MESH] Vasseur, JP., Le Roux, JL., et al., "Routing extensions for | ||||
discovery of Multiprotocol (MPLS) Label Switch Router (LSR) | ||||
Traffic Engineering (TE) mesh membership", draft-ietf-ccamp- | ||||
automesh, work in progress. | ||||
9. Authors' Addresses | 9. Authors' Addresses | |||
Kohei Shiomoto | Kohei Shiomoto | |||
NTT Network Service Systems Laboratories | NTT Network Service Systems Laboratories | |||
3-9-11 Midori-cho, | 3-9-11 Midori-cho, | |||
Musashino-shi, Tokyo 180-8585, Japan | Musashino-shi, Tokyo 180-8585, Japan | |||
Email: shiomoto.kohei@lab.ntt.co.jp | Email: shiomoto.kohei@lab.ntt.co.jp | |||
Dimitri Papadimitriou | Dimitri Papadimitriou | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Francis Wellensplein 1, | 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, France | |||
Email: jeanlouis.leroux@orange-ft.com | Email: jeanlouis.leroux@orange-ft.com | |||
skipping to change at page 21, line 4 | skipping to change at page 20, line 4 | |||
Route de Nozay, 91461 Marcoussis cedex, France | Route de Nozay, 91461 Marcoussis cedex, France | |||
Phone: +33 (0)1 69 63 18 52 | Phone: +33 (0)1 69 63 18 52 | |||
Email: martin.vigoureux@alcatel-lucent.fr | 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 | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
10.Contributors' Addresses | 10.Contributors' Addresses | |||
Eiji Oki | Eiji Oki | |||
NTT Network Service Systems Laboratories | NTT Network Service Systems Laboratories | |||
3-9-11 Midori-cho, | 3-9-11 Midori-cho, | |||
Musashino-shi, | Musashino-shi, | |||
Tokyo 180-8585, | Tokyo 180-8585, | |||
Japan | Japan | |||
Phone: +81 422 59 3441 | Phone: +81 422 59 3441 | |||
Email: oki.eiji@lab.ntt.co.jp | Email: oki.eiji@lab.ntt.co.jp | |||
skipping to change at page 21, line 34 | skipping to change at page 20, line 36 | |||
Emmanuel Dotaro | Emmanuel Dotaro | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Route de Nozay, | Route de Nozay, | |||
91461 Marcoussis cedex, | 91461 Marcoussis cedex, | |||
France | France | |||
Phone : +33 1 6963 4723 | Phone : +33 1 6963 4723 | |||
Email: emmanuel.dotaro@alcatel-lucent.fr | Email: emmanuel.dotaro@alcatel-lucent.fr | |||
11. Intellectual Property Considerations | 11. Intellectual Property Considerations | |||
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 | |||
Intellectual Property Rights or other rights that might be claimed | Property Rights or other rights that might be claimed to pertain to the | |||
to pertain to the implementation or use of the technology described | implementation or use of the technology described in this document or the extent | |||
in this document or the extent to which any license under such | to which any license under such rights might or might not be available; nor does | |||
rights might or might not be available; nor does it represent that | it represent that it has made any independent effort to identify any such rights. | |||
it has made any independent effort to identify any such rights. | Information on the procedures with respect to rights in RFC documents can be | |||
Information on the procedures with respect to rights in RFC | found in BCP 78 and BCP 79. | |||
documents can be 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 | |||
assurances of licenses to be made available, or the result of an | licenses to be made available, or the result of an attempt made to obtain a | |||
attempt made to obtain a general license or permission for the use | general license or permission for the use of such proprietary rights by | |||
of such proprietary rights by implementers or users of this | implementers or users of this specification can be obtained from the IETF on- | |||
specification can be obtained from the IETF on-line IPR repository | line IPR repository at http://www.ietf.org/ipr. | |||
at 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, | |||
copyrights, patents or patent applications, or other proprietary | patents or patent applications, or other proprietary rights that may cover | |||
rights that may cover technology that may be required to implement | technology that may be required to implement this standard. Please address the | |||
this standard. Please address the information to the IETF at ietf- | information to the IETF at ietf-ipr@ietf.org. | |||
ipr@ietf.org. | ||||
12. Full Copyright Statement | 12. Full Copyright Statement | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
Copyright (C) The IETF Trust (2007). This document is subject to | Copyright (C) The IETF Trust (2007). This document is subject to the rights, | |||
the rights, licenses and restrictions contained in BCP 78, and | licenses and restrictions contained in BCP 78, and except as set forth therein, | |||
except as set forth therein, the authors retain all their rights. | the authors retain all their rights. | |||
This document and the information contained herein are provided on | This document and the information contained herein are provided on an "AS IS" | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY | |||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING | |||
IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT | |||
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | |||
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | |||
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | PARTICULAR PURPOSE. | |||
FOR A PARTICULAR PURPOSE. | ||||
End of changes. 127 change blocks. | ||||
714 lines changed or deleted | 723 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |