draft-ietf-ccamp-gmpls-architecture-02.txt   draft-ietf-ccamp-gmpls-architecture-03.txt 
Network Working Group Eric Mannie (Ebone) - Editor CCAMP Working Group Eric Mannie - Editor
Internet Draft Internet Draft
Expiration date: Sept. 2002 Peter Ashwood-Smith (Nortel) Expiration date: Feb. 2003 August 2002
Daniel Awduche (Movaz)
Ayan Banerjee (Calient)
Debashis Basak (Accelight)
Lou Berger (Movaz)
Greg Bernstein (Ciena)
Sudheer Dharanikota (Nayna)
John Drake (Calient)
Yanhe Fan (Axiowave)
Don Fedyk (Nortel)
Gert Grammel (Alcatel)
Dan Guo (Turin)
Kireeti Kompella (Juniper)
Alan Kullberg (NetPlane)
Jonathan P. Lang (Calient)
Fong Liaw (Zaffire)
Thomas D. Nadeau (Cisco)
Lyndon Ong (Ciena)
Dimitri Papadimitriou (Alcatel)
Dimitrios Pendarakis (Tellium)
Bala Rajagopalan (Tellium)
Yakov Rekhter (Juniper)
Debanjan Saha (Tellium)
Hal Sandick (Nortel)
Vishal Sharma (Metanoia)
George Swallow (Cisco)
Z. Bo Tang (Tellium)
Jennifer Yates (AT&T)
George R. Young (Edgeflow)
John Yu (Zaffire)
Alex Zinin (Nexsi Systems)
March 2002
Generalized Multi-Protocol Label Switching (GMPLS) Architecture Generalized Multi-Protocol Label Switching (GMPLS) Architecture
draft-ietf-ccamp-gmpls-architecture-02.txt draft-ietf-ccamp-gmpls-architecture-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
E. Mannie et. al. 1
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
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 updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in 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.
Table of Contents Abstract
Status of this Memo................................................1
Table of Contents..................................................2
1. Abstract........................................................4
2. Conventions used in this document...............................4
3. Introduction....................................................4
3.1. Acronyms & abbreviations......................................5
3.2. Multiple Types of Switching and Forwarding Hierarchies........5
3.3. Extension of the MPLS Control Plane...........................7
3.4. GMPLS Key Extensions to MPLS-TE..............................10
4. Routing and addressing model...................................11
4.1. Addressing of PSC and non-PSC layers.........................12
4.2. GMPLS scalability enhancements...............................12
4.3. TE Extensions to IP routing protocols........................13
5. Unnumbered links...............................................14
5.1. Unnumbered Forwarding Adjacencies............................15
6. Link bundling..................................................15
6.1. Restrictions on bundling.....................................16
6.2. Routing considerations for bundling..........................16
6.3. Signaling considerations.....................................17
6.3.1. Mechanism 1: Implicit Indication...........................17
6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID..17
6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID17
6.4. Unnumbered Bundled Link......................................18
6.5. Forming bundled links........................................18
7. Relationship with the UNI......................................19
7.1. Relationship with the OIF UNI................................19
7.2. Reachability across the UNI..................................19
8. Link Management................................................20
8.1. Control channel and control channel management...............21
8.2. Link property correlation....................................22
8.3. Link connectivity verification...............................22
8.4. Fault management.............................................23
8.5 LMP for DWDM Optical Line Systems (OLSs)......................23
9. Generalized Signaling..........................................25
9.1. Overview: How to Request an LSP..............................26
9.2. Generalized Label Request....................................27
9.3. SONET/SDH Traffic Parameters.................................28
9.4. G.709 Traffic Parameters.....................................29
9.5. Bandwidth Encoding...........................................30
9.6. Generalized Label............................................30
9.7. Waveband Switching...........................................31
E. Mannie et. al. Internet-Draft September 2002 2
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
9.8. Label Suggestion by the Upstream.............................31
9.9. Label Restriction by the Upstream............................32
9.10. Bi-directional LSP..........................................32
9.11. Bi-directional LSP Contention Resolution....................33
9.12. Rapid Notification of Failure...............................33
9.13. Link Protection.............................................34
9.14. Explicit Routing and Explicit Label Control.................35
9.15. Route recording.............................................36
9.16. LSP modification and LSP re-routing.........................36
9.17. LSP administrative status handling..........................37
9.18. Control channel separation..................................37
10. Forwarding Adjacencies (FA)...................................38
10.1. Routing and Forwarding Adjacencies..........................39
10.2. Signaling aspects...........................................40
10.3. Cascading of Forwarding Adjacencies.........................40
11. Routing and Signaling Adjacencies.............................41
12. Control Plane Fault Handling..................................42
13. LSP Protection and Restoration................................43
13.1. Protection escalation across domains and layers.............43
13.2. Mapping of Services to P&R Resources........................44
13.3. Classification of P&R mechanism characteristics.............45
13.4. Different Stages in P&R.....................................45
13.5. Recovery Strategies.........................................46
13.6. Recovery mechanisms: Protection schemes.....................46
13.7. Recovery mechanisms: Restoration schemes....................47
13.8. Schema selection criteria...................................48
14. Network Management............................................49
14.1. Network Management Systems (NMS)............................49
14.2. Management Information Base (MIB)...........................50
14.3. Tools.......................................................50
14.4. Fault Correlation Between Multiple Layers...................50
15. Security considerations.......................................51
16. Acknowledgements..............................................52
17. References....................................................53
18. Author's Addresses............................................55
Full Copyright Statement..........................................58
E. Mannie et. al. Internet-Draft September 2002 3
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
1. Abstract
Future data and transmission networks will consist of elements such Future data and transmission networks will consist of elements such
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs),
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc photonic cross-connects (PXCs), optical cross-connects (OXCs), etc
that will use Generalized MPLS (GMPLS) to dynamically provision that will use Generalized MPLS (GMPLS) to dynamically provision
resources and to provide network survivability using protection and resources and to provide network survivability using protection and
restoration techniques. restoration techniques.
This document describes the architecture of GMPLS. GMPLS extends This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709), MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The main focus of GMPLS is on the fiber to outgoing port or fiber). The main focus of GMPLS is on the
control plane of these various layers since each of them can use control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane. cover both the signaling and the routing part of that control plane.
E. Mannie et. al. 1
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
1. Contributors....................................................4
2. Conventions used in this document...............................7
3. Introduction....................................................7
3.1. Acronyms & abbreviations......................................7
3.2. Multiple Types of Switching and Forwarding Hierarchies........8
3.3. Extension of the MPLS Control Plane..........................10
3.4. GMPLS Key Extensions to MPLS-TE..............................12
4. Routing and addressing model...................................13
4.1. Addressing of PSC and non-PSC layers.........................14
4.2. GMPLS scalability enhancements...............................15
4.3. TE Extensions to IP routing protocols........................15
5. Unnumbered links...............................................16
5.1. Unnumbered Forwarding Adjacencies............................17
6. Link bundling..................................................18
6.1. Restrictions on bundling.....................................18
6.2. Routing considerations for bundling..........................18
6.3. Signaling considerations.....................................19
6.3.1. Mechanism 1: Implicit Indication...........................20
6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID..20
6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID20
6.4. Unnumbered Bundled Link......................................20
6.5. Forming bundled links........................................21
7. Relationship with the UNI......................................21
7.1. Relationship with the OIF UNI................................22
7.2. Reachability across the UNI..................................22
8. Link Management................................................23
8.1. Control channel and control channel management...............23
8.2. Link property correlation....................................25
8.3. Link connectivity verification...............................25
8.4. Fault management.............................................25
8.5 LMP for DWDM Optical Line Systems (OLSs)......................26
9. Generalized Signaling..........................................27
9.1. Overview: How to Request an LSP..............................29
9.2. Generalized Label Request....................................30
9.3. SONET/SDH Traffic Parameters.................................31
9.4. G.709 Traffic Parameters.....................................32
9.5. Bandwidth Encoding...........................................32
9.6. Generalized Label............................................33
9.7. Waveband Switching...........................................33
9.8. Label Suggestion by the Upstream.............................34
9.9. Label Restriction by the Upstream............................34
9.10. Bi-directional LSP..........................................35
9.11. Bi-directional LSP Contention Resolution....................36
9.12. Rapid Notification of Failure...............................36
9.13. Link Protection.............................................37
9.14. Explicit Routing and Explicit Label Control.................37
9.15. Route recording.............................................38
9.16. LSP modification and LSP re-routing.........................39
9.17. LSP administrative status handling..........................39
E. Mannie et. al. Internet-Draft February 2003 2
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
9.18. Control channel separation..................................40
10. Forwarding Adjacencies (FA)...................................41
10.1. Routing and Forwarding Adjacencies..........................41
10.2. Signaling aspects...........................................42
10.3. Cascading of Forwarding Adjacencies.........................42
11. Routing and Signaling Adjacencies.............................43
12. Control Plane Fault Handling..................................44
13. LSP Protection and Restoration................................45
13.1. Protection escalation across domains and layers.............46
13.2. Mapping of Services to P&R Resources........................46
13.3. Classification of P&R mechanism characteristics.............47
13.4. Different Stages in P&R.....................................47
13.5. Recovery Strategies.........................................48
13.6. Recovery mechanisms: Protection schemes.....................48
13.7. Recovery mechanisms: Restoration schemes....................49
13.8. Schema selection criteria...................................50
14. Network Management............................................51
14.1. Network Management Systems (NMS)............................51
14.2. Management Information Base (MIB)...........................52
14.3. Tools.......................................................52
14.4. Fault Correlation Between Multiple Layers...................52
15. Security considerations.......................................53
16. Acknowledgements..............................................54
17. References....................................................55
18. Author's Address..............................................57
Full Copyright Statement..........................................58
E. Mannie et. al. Internet-Draft February 2003 3
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
1. Contributors
Peter Ashwood-Smith Eric Mannie
Nortel Networks Corp. Ebone (GTS)
P.O. Box 3511 Station C, Terhulpsesteenweg 6A
Ottawa, ON K1Y 4H7 1560 Hoeilaart
Canada Belgium
Phone: +1 613 763-4534 Phone: +32 2 658-5652
Email: Email: eric.mannie@gts.com
petera@nortelnetworks.com
Daniel O. Awduche Thomas D. Nadeau
Movaz Networks Cisco Systems, Inc.
7296 Jones Branch Drive 250 Apollo Drive
Suite 615 Chelmsford, MA 01824
McLean, VA 22102 USA
USA Phone: +1 978 244-3051
Phone: +1 703 847-7350 Email: tnadeau@cisco.com
Email: awduche@movaz.com
Ayan Banerjee Lyndon Ong
Calient Networks Ciena Systems
5853 Rue Ferrari 10480 Ridgeview Ct
San Jose, CA 95138 Cupertino, CA 95014
USA USA
Phone: +1 408 972-3645 Email: lyong@ciena.com
Email: abanerjee@calient.net
Debashis Basak Dimitri Papadimitriou
Accelight Networks Alcatel
70 Abele Road, Bldg.1200 Francis Wellesplein, 1
Bridgeville, PA 15017 B-2018 Antwerpen
USA Belgium
Phone: +1 412 220-2102 (ext115) Phone: +32 3 240-8491
email: dbasak@accelight.com Email:
dimitri.papadimitriou@alcatel.be
Lou Berger Dimitrios Pendarakis
Movaz Networks, Inc. Tellium, Inc.
7926 Jones Branch Drive 2 Crescent Place
Suite 615 P.O. Box 901
MCLean VA, 22102 Oceanport, NJ 07757-0901
USA USA
Phone: +1 703 847-1801 Email: DPendarakis@tellium.com
Email: lberger@movaz.com
E. Mannie et. al. Internet-Draft February 2003 4
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Greg Bernstein Bala Rajagopalan
Ciena Corporation Tellium, Inc.
10480 Ridgeview Court 2 Crescent Place
Cupertino, CA 94014 P.O. Box 901
USA Oceanport, NJ 07757-0901
Phone: +1 408 366-4713 USA
Email: greg@ciena.com Phone: +1 732 923-4237
Email: braja@tellium.com
Sudheer Dharanikota Yakov Rekhter
Nayna Networks Inc. Juniper
481 Sycamore Drive Email: yakov@juniper.net
Milpitas, CA 95035
USA
Email: sudheer@nayna.com
John Drake Debanjan Saha
Calient Networks Tellium Optical Systems
5853 Rue Ferrari 2 Crescent Place
San Jose, CA 95138 Oceanport, NJ 07757-0901
USA USA
Phone: +1 408 972-3720 Phone: +1 732 923-4264
Email: jdrake@calient.net Email: dsaha@tellium.com
Yanhe Fan Hal Sandick
Axiowave Networks, Inc. Nortel Networks
200 Nickerson Road Email:
Marlborough, MA 01752 hsandick@nortelnetworks.com
USA
Phone: +1 774 348-4627
Email: yfan@axiowave.com
Don Fedyk Vishal Sharma
Nortel Networks Corp. Metanoia, Inc.
600 Technology Park Drive 305 Elan Village Lane, Unit
Billerica, MA 01821 121
USA San Jose, CA 95134-2545
Phone: +1 978 288-4506 USA
Email: Phone: +1 408 895-5030
dwfedyk@nortelnetworks.com Email: vsharma87@yahoo.com
Gert Grammel George Swallow
Alcatel Cisco Systems, Inc.
Via Trento, 30 250 Apollo Drive
20059 Vimercate (Mi) Chelmsford, MA 01824
Italy USA
Email: gert.grammel@alcatel.it Phone: +1 978 244-8143
Email: swallow@cisco.com
E. Mannie et. al. Internet-Draft February 2003 5
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Dan Guo Z. Bo Tang
Turin Networks, Inc. Tellium, Inc.
1415 N. McDowell Blvd, 2 Crescent Place
Petaluma, CA 95454 P.O. Box 901
USA Oceanport, NJ 07757-0901
Email: dguo@turinnetworks.com USA
Phone: +1 732 923-4231
Email: btang@tellium.com
Kireeti Kompella Jennifer Yates
Juniper Networks, Inc. AT&T
1194 N. Mathilda Ave. 180 Park Avenue
Sunnyvale, CA 94089 Florham Park, NJ 07932
USA USA
Email: kireeti@juniper.net Email: jyates@research.att.com
Alan Kullberg George R. Young
NetPlane Systems, Inc. Edgeflow
888 Washington St. 329 March Road
Dedham, MA 02026 Ottawa, Ontario, K2K 2E1
USA Canada
Phone: +1 781 251-5319 Email:
Email: akullber@netplane.com george.young@edgeflow.com
Jonathan P. Lang John Yu
Calient Networks Zaffire Inc.
25 Castilian 2630 Orchard Parkway
Goleta, CA 93117 San Jose, CA 95134
Email: jplang@calient.net USA
Email: jzyu@zaffire.com
Fong Liaw Alex Zinin
Zaffire Inc. Alcatel
2630 Orchard Parkway 1420 North McDowell Ave
San Jose, CA 95134 M/S 1400-HRPB6
USA Petaluma, CA 94954
Email: fliaw@zaffire.com USA
Email: alex.zinin@alcatel.com
E. Mannie et. al. Internet-Draft February 2003 6
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2]. this document are to be interpreted as described in RFC-2119 [2].
3. Introduction 3. Introduction
The architecture presented in this document covers the main building The architecture presented in this document covers the main building
blocks needed to build a consistent control plane for multiple blocks needed to build a consistent control plane for multiple
skipping to change at line 205 skipping to change at line 317
concepts already described in the current MPLS architecture. The concepts already described in the current MPLS architecture. The
goal is to describe specific concepts of Generalized MPLS (GMPLS). goal is to describe specific concepts of Generalized MPLS (GMPLS).
However, some of the concepts explained hereafter are not part of However, some of the concepts explained hereafter are not part of
the current MPLS architecture and are applicable to both MPLS and the current MPLS architecture and are applicable to both MPLS and
GMPLS (i.e. link bundling, unnumbered links, and LSP hierarchy). GMPLS (i.e. link bundling, unnumbered links, and LSP hierarchy).
Since these concepts were introduced together with GMPLS and since Since these concepts were introduced together with GMPLS and since
they are of paramount importance for an operational GMPLS network, they are of paramount importance for an operational GMPLS network,
they will be discussed here. they will be discussed here.
E. Mannie et. al. Internet-Draft September 2002 4
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
The organization of the remainder of this draft is as follows. We The organization of the remainder of this draft is as follows. We
begin with an introduction of GMPLS. We then present the specific begin with an introduction of GMPLS. We then present the specific
GMPLS building blocks and explain how they can be combined together GMPLS building blocks and explain how they can be combined together
to build an operational GMPLS networks. Specific details of the to build an operational GMPLS networks. Specific details of the
separate building blocks can be found in the corresponding separate building blocks can be found in the corresponding
documents. documents.
3.1. Acronyms & abbreviations 3.1. Acronyms & abbreviations
ABR Area Border Router ABR Area Border Router
AS Autonomous System AS Autonomous System
ASBR Autonomous System Boundary Router ASBR Autonomous System Boundary Router
BGP Border Gateway Protocol BGP Border Gateway Protocol
CR-LDP Constraint-based Routing LDP CR-LDP Constraint-based Routing LDP
CSPF Constraint-based Shortest Path First CSPF Constraint-based Shortest Path First
DWDM Dense Wavelength Division Multiplexing DWDM Dense Wavelength Division Multiplexing
FA Forwarding Adjacency FA Forwarding Adjacency
GMPLS Generalized Multi-Protocol Label Switching GMPLS Generalized Multi-Protocol Label Switching
IGP Interior Gateway Protocol IGP Interior Gateway Protocol
E. Mannie et. al. Internet-Draft February 2003 7
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
LDP Label Distribution Protocol LDP Label Distribution Protocol
LMP Link Management Protocol LMP Link Management Protocol
LSA Link State Advertisement LSA Link State Advertisement
LSR Label Switching Router LSR Label Switching Router
LSP Label Switched Path LSP Label Switched Path
MIB Management Information Base MIB Management Information Base
MPLS Multi-Protocol Label Switching MPLS Multi-Protocol Label Switching
NMS Network Management System NMS Network Management System
OXC Optical Cross-Connect OXC Optical Cross-Connect
PXC Photonic Cross-Connect PXC Photonic Cross-Connect
skipping to change at line 263 skipping to change at line 376
information provided for synchronizing the ingress and egress LSRs. information provided for synchronizing the ingress and egress LSRs.
The MPLS architecture [RFC3031] was defined to support the The MPLS architecture [RFC3031] was defined to support the
forwarding of data based on a label. In this architecture, Label forwarding of data based on a label. In this architecture, Label
Switching Routers (LSRs) were assumed to have a forwarding plane Switching Routers (LSRs) were assumed to have a forwarding plane
that is capable of (a) recognizing either packet or cell boundaries, that is capable of (a) recognizing either packet or cell boundaries,
and (b) being able to process either packet headers (for LSRs and (b) being able to process either packet headers (for LSRs
capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs
capable of recognizing cell boundaries). capable of recognizing cell boundaries).
E. Mannie et. al. Internet-Draft September 2002 5
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
The original MPLS architecture is here being extended to include The original MPLS architecture is here being extended to include
LSRs whose forwarding plane recognizes neither packet, nor cell LSRs whose forwarding plane recognizes neither packet, nor cell
boundaries, and therefore, can't forward data based on the boundaries, and therefore, can't forward data based on the
information carried in either packet or cell headers. Specifically, information carried in either packet or cell headers. Specifically,
such LSRs include devices where the forwarding decision is based on such LSRs include devices where the forwarding decision is based on
time slots, wavelengths, or physical ports. So, the new set of LSRs, time slots, wavelengths, or physical ports. So, the new set of LSRs,
or more precisely interfaces on these LSRs, can be subdivided into or more precisely interfaces on these LSRs, can be subdivided into
the following classes: the following classes:
1. Packet Switch Capable (PSC) interfaces: 1. Packet Switch Capable (PSC) interfaces:
Interfaces that recognize packet boundaries and can forward data Interfaces that recognize packet boundaries and can forward data
based on the content of the packet header. Examples include based on the content of the packet header. Examples include
interfaces on routers that forward data based on the content of the interfaces on routers that forward data based on the content of the
IP header and interfaces on routers that forward data based on the IP header and interfaces on routers that forward data based on the
content of the MPLS "shim" header. content of the MPLS "shim" header.
2. Layer-2 Switch Capable (L2SC) interfaces: 2. Layer-2 Switch Capable (L2SC) interfaces:
E. Mannie et. al. Internet-Draft February 2003 8
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Interfaces that recognize frame/cell boundaries and can forward data Interfaces that recognize frame/cell boundaries and can forward data
based on the content of the frame/cell header. Examples include based on the content of the frame/cell header. Examples include
interfaces on Ethernet bridges that forward data based on the interfaces on Ethernet bridges that forward data based on the
content of the MAC header and interfaces on ATM-LSRs that forward content of the MAC header and interfaces on ATM-LSRs that forward
data based on the ATM VPI/VCI. data based on the ATM VPI/VCI.
3. Time-Division Multiplex Capable (TDM) interfaces: 3. Time-Division Multiplex Capable (TDM) interfaces:
Interfaces that forward data based on the data's time slot in a Interfaces that forward data based on the data's time slot in a
repeating cycle. An example of such an interface is that of a repeating cycle. An example of such an interface is that of a
skipping to change at line 319 skipping to change at line 432
5. Fiber-Switch Capable (FSC) interfaces: 5. Fiber-Switch Capable (FSC) interfaces:
Interfaces that forward data based on a position of the data in the Interfaces that forward data based on a position of the data in the
real world physical spaces. An example of such an interface is that real world physical spaces. An example of such an interface is that
of a PXC or OXC that can operate at the level of a single or of a PXC or OXC that can operate at the level of a single or
multiple fibers. multiple fibers.
A circuit can be established only between, or through, interfaces of A circuit can be established only between, or through, interfaces of
the same type. Depending on the particular technology being used for the same type. Depending on the particular technology being used for
each interface, different circuit names can be used, e.g. SDH each interface, different circuit names can be used, e.g. SDH
E. Mannie et. al. Internet-Draft September 2002 6
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
circuit, optical trail, light-path, etc. In the context of GMPLS, circuit, optical trail, light-path, etc. In the context of GMPLS,
all these circuits are referenced by a common name: Label Switched all these circuits are referenced by a common name: Label Switched
Path (LSP). Path (LSP).
The concept of nested LSP (LSP within LSP), already available in the The concept of nested LSP (LSP within LSP), already available in the
traditional MPLS, facilitates building a forwarding hierarchy, i.e. traditional MPLS, facilitates building a forwarding hierarchy, i.e.
a hierarchy of LSPs. This hierarchy of LSPs can occur on the same a hierarchy of LSPs. This hierarchy of LSPs can occur on the same
interface, or between different interfaces. interface, or between different interfaces.
For example, a hierarchy can be built if an interface is capable of For example, a hierarchy can be built if an interface is capable of
multiplexing several LSPs from the same technology (layer), e.g. a multiplexing several LSPs from the same technology (layer), e.g. a
lower order SDH/SONET LSP (VC-12) nested in a higher order SDH/SONET lower order SDH/SONET LSP (VC-12) nested in a higher order SDH/SONET
LSP (VC-4). Several levels of signal (LSP) nesting are defined in LSP (VC-4). Several levels of signal (LSP) nesting are defined in
the SDH/SONET multiplexing hierarchy. the SDH/SONET multiplexing hierarchy.
The nesting can also occur between interfaces. At the top of the The nesting can also occur between interfaces. At the top of the
hierarchy are FSC interfaces, followed by LSC interfaces, followed hierarchy are FSC interfaces, followed by LSC interfaces, followed
by TDM interfaces, followed by L2SC, and followed by PSC interfaces. by TDM interfaces, followed by L2SC, and followed by PSC interfaces.
This way, an LSP that starts and ends on a PSC interface can be This way, an LSP that starts and ends on a PSC interface can be
E. Mannie et. al. Internet-Draft February 2003 9
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
nested (together with other LSPs) into an LSP that starts and ends nested (together with other LSPs) into an LSP that starts and ends
on a L2SC interface. This LSP, in turn, can be nested (together with on a L2SC interface. This LSP, in turn, can be nested (together with
other LSPs) into an LSP that starts and ends on an TDM interface, other LSPs) into an LSP that starts and ends on an TDM interface,
which in turn can be nested (together with other LSPs) into an LSP which in turn can be nested (together with other LSPs) into an LSP
that starts and ends on a LSC interface, which in turn can be nested that starts and ends on a LSC interface, which in turn can be nested
(together with other LSPs) into an LSP that starts and ends on a FSC (together with other LSPs) into an LSP that starts and ends on a FSC
interface. interface.
3.3. Extension of the MPLS Control Plane 3.3. Extension of the MPLS Control Plane
skipping to change at line 377 skipping to change at line 490
have been extended and/or modified to support GMPLS. They use IPv4 have been extended and/or modified to support GMPLS. They use IPv4
and/or IPv6 addresses. Only one new specialized protocol is required and/or IPv6 addresses. Only one new specialized protocol is required
to support the operations of GMPLS, a signaling protocol for link to support the operations of GMPLS, a signaling protocol for link
management [LMP]. management [LMP].
GMPLS is indeed based on the Traffic Engineering (TE) extensions to GMPLS is indeed based on the Traffic Engineering (TE) extensions to
MPLS, a.k.a. MPLS-TE. This because most of the technologies that can MPLS, a.k.a. MPLS-TE. This because most of the technologies that can
be used below the PSC level require some traffic engineering. The be used below the PSC level require some traffic engineering. The
placement of LSPs at these levels needs in general to take several placement of LSPs at these levels needs in general to take several
constraints into consideration (such as framing, bandwidth, constraints into consideration (such as framing, bandwidth,
E. Mannie et. al. Internet-Draft September 2002 7
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
protection capability, etc) and to bypass the legacy Shortest-Path protection capability, etc) and to bypass the legacy Shortest-Path
First (SPF) algorithm. Note, however, that this is not mandatory and First (SPF) algorithm. Note, however, that this is not mandatory and
that in some cases SPF routing can be applied. that in some cases SPF routing can be applied.
In order to facilitate constrained-based SPF routing of LSPs, the In order to facilitate constrained-based SPF routing of LSPs, the
nodes performing LSP establishment need more information about the nodes performing LSP establishment need more information about the
links in the network than standard intra-domain routing protocols links in the network than standard intra-domain routing protocols
provide. These TE attributes are distributed using the transport provide. These TE attributes are distributed using the transport
mechanisms already available in IGPs (e.g. flooding) and taken into mechanisms already available in IGPs (e.g. flooding) and taken into
consideration by the LSP routing algorithm. Optimization of the LSP consideration by the LSP routing algorithm. Optimization of the LSP
routes may also require some external simulations using heuristics routes may also require some external simulations using heuristics
that serve as input for the actual path calculation and LSP that serve as input for the actual path calculation and LSP
establishment process. establishment process.
By definition, a TE link is a representation in the ISIS/OSPF Link By definition, a TE link is a representation in the ISIS/OSPF Link
State advertisements and in the link state database of certain State advertisements and in the link state database of certain
physical resources, and their properties, between two GMPLS nodes. physical resources, and their properties, between two GMPLS nodes.
TE Links are used by the GMPLS control plane (routing and signaling) TE Links are used by the GMPLS control plane (routing and signaling)
for establishing LSPs. for establishing LSPs.
E. Mannie et. al. Internet-Draft February 2003 10
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Extensions to traditional routing protocols and algorithms are Extensions to traditional routing protocols and algorithms are
needed to uniformly encode and carry TE link information, and needed to uniformly encode and carry TE link information, and
explicit routes (e.g. source routes) are required in the signaling. explicit routes (e.g. source routes) are required in the signaling.
In addition, the signaling must now be capable of transporting the In addition, the signaling must now be capable of transporting the
required circuit (LSP) parameters such as the bandwidth, the type of required circuit (LSP) parameters such as the bandwidth, the type of
signal, the desired protection and/or restoration, the position in a signal, the desired protection and/or restoration, the position in a
particular multiplex, etc. Most of these extensions have already particular multiplex, etc. Most of these extensions have already
been defined for PSC and L2SC traffic engineering with MPLS. GMPLS been defined for PSC and L2SC traffic engineering with MPLS. GMPLS
primarily defines additional extensions for TDM, LSC, and FSC primarily defines additional extensions for TDM, LSC, and FSC
traffic engineering. A very few elements are technology specific. traffic engineering. A very few elements are technology specific.
skipping to change at line 436 skipping to change at line 548
explicit routing is normally used (strict or loose) but hop-by-hop explicit routing is normally used (strict or loose) but hop-by-hop
routing could be used as well. routing could be used as well.
GMPLS also extends two traditional intra-domain link-state routing GMPLS also extends two traditional intra-domain link-state routing
protocols already extended for TE purposes, i.e. OSPF-TE and IS-IS- protocols already extended for TE purposes, i.e. OSPF-TE and IS-IS-
TE. However, if explicit (source) routing is used, the routing TE. However, if explicit (source) routing is used, the routing
algorithms used by these protocols no longer need to be algorithms used by these protocols no longer need to be
standardized. Extensions for inter-domain routing (e.g. BGP) are for standardized. Extensions for inter-domain routing (e.g. BGP) are for
further study. further study.
E. Mannie et. al. Internet-Draft September 2002 8
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
The use of technologies like DWDM (Dense Wavelength Division The use of technologies like DWDM (Dense Wavelength Division
Multiplexing) implies that we can now have a very large number of Multiplexing) implies that we can now have a very large number of
parallel links between two directly adjacent nodes (hundreds of parallel links between two directly adjacent nodes (hundreds of
wavelengths, or even thousands of wavelengths if multiple fibers are wavelengths, or even thousands of wavelengths if multiple fibers are
used). Such a large number of links was not originally considered used). Such a large number of links was not originally considered
for an IP or MPLS control plane, although it could be done. Some for an IP or MPLS control plane, although it could be done. Some
slight adaptations of that control plane are thus required if we slight adaptations of that control plane are thus required if we
want to better reuse it in the GMPLS context. want to better reuse it in the GMPLS context.
For instance, the traditional IP routing model assumes the For instance, the traditional IP routing model assumes the
establishment of a routing adjacency over each link connecting two establishment of a routing adjacency over each link connecting two
adjacent nodes. Having such a large number of adjacencies does not adjacent nodes. Having such a large number of adjacencies does not
scale well. Each node needs to maintain each of its adjacencies one scale well. Each node needs to maintain each of its adjacencies one
by one, and link state routing information must be flooded by one, and link state routing information must be flooded
throughout the network. throughout the network.
To solve this issue the concept of link bundling was introduced. To solve this issue the concept of link bundling was introduced.
Moreover, the manual configuration and control of these links, even Moreover, the manual configuration and control of these links, even
E. Mannie et. al. Internet-Draft February 2003 11
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
if they are unnumbered, becomes impractical. The Link Management if they are unnumbered, becomes impractical. The Link Management
Protocol (LMP) was specified to solve these issues. Protocol (LMP) was specified to solve these issues.
LMP runs between data plane adjacent nodes and is used to manage TE LMP runs between data plane adjacent nodes and is used to manage TE
links. Specifically, LMP provides mechanisms to maintain control links. Specifically, LMP provides mechanisms to maintain control
channel connectivity (IP Control Channel Maintenance), verify the channel connectivity (IP Control Channel Maintenance), verify the
physical connectivity of the data-bearing links (Link Verification), physical connectivity of the data-bearing links (Link Verification),
correlate the link property information (Link Property Correlation), correlate the link property information (Link Property Correlation),
and manage link failures (Fault Localization and Fault and manage link failures (Fault Localization and Fault
Notification). A unique feature of LMP is that it is able to Notification). A unique feature of LMP is that it is able to
skipping to change at line 490 skipping to change at line 603
manage these control channels. manage these control channels.
GMPLS does not specify how these control channels must be GMPLS does not specify how these control channels must be
implemented, but GMPLS requires IP to transport the signaling and implemented, but GMPLS requires IP to transport the signaling and
routing protocols over them. Control channels can be either in-band routing protocols over them. Control channels can be either in-band
or out-of-band, and several solutions can be used to carry IP. Note or out-of-band, and several solutions can be used to carry IP. Note
also that one type of LMP message (the Test message) is used in-band also that one type of LMP message (the Test message) is used in-band
in the data plane and may not be transported over IP, but this is a in the data plane and may not be transported over IP, but this is a
particular case, needed to verify connectivity in the data plane. particular case, needed to verify connectivity in the data plane.
E. Mannie et. al. Internet-Draft September 2002 9
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
3.4. GMPLS Key Extensions to MPLS-TE 3.4. GMPLS Key Extensions to MPLS-TE
Some key extensions brought by GMPLS to MPLS-TE are highlighted in Some key extensions brought by GMPLS to MPLS-TE are highlighted in
the following. Some of them are key advantages of GMPLS to control the following. Some of them are key advantages of GMPLS to control
TDM, LSC and FSC layers. TDM, LSC and FSC layers.
- In MPLS-TE, links traversed by an LSP can include an intermix of - In MPLS-TE, links traversed by an LSP can include an intermix of
links with heterogeneous label encoding (e.g. links between routers, links with heterogeneous label encoding (e.g. links between routers,
links between routers and ATM-LSRs, and links between ATM-LSRs. links between routers and ATM-LSRs, and links between ATM-LSRs.
GMPLS extends this by including links where the label is encoded as GMPLS extends this by including links where the label is encoded as
skipping to change at line 514 skipping to change at line 624
physical space. physical space.
- In MPLS-TE, an LSP that carries IP has to start and end on a - In MPLS-TE, an LSP that carries IP has to start and end on a
router. GMPLS extends this by requiring an LSP to start and end on router. GMPLS extends this by requiring an LSP to start and end on
similar type of LSR. similar type of LSR.
- The type of a payload that can be carried in GMPLS by an LSP is - The type of a payload that can be carried in GMPLS by an LSP is
extended to allow such payloads as SONET/SDH, G.709, 1 or 10Gb extended to allow such payloads as SONET/SDH, G.709, 1 or 10Gb
Ethernet, etc. Ethernet, etc.
E. Mannie et. al. Internet-Draft February 2003 12
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
- The use of Forwarding Adjacencies (FA), provides a mechanism that - The use of Forwarding Adjacencies (FA), provides a mechanism that
can improve bandwidth utilization, when bandwidth allocation can be can improve bandwidth utilization, when bandwidth allocation can be
performed only in discrete units, as well as a mechanism to performed only in discrete units, as well as a mechanism to
aggregate forwarding state, thus allowing the number of required aggregate forwarding state, thus allowing the number of required
labels to be reduced. labels to be reduced.
- GMPLS allows for a label to be suggested by an upstream node to - GMPLS allows for a label to be suggested by an upstream node to
reduce the setup latency. This suggestion may be overridden by a reduce the setup latency. This suggestion may be overridden by a
downstream node but, in some cases, at the cost of higher LSP setup downstream node but, in some cases, at the cost of higher LSP setup
time. time.
skipping to change at line 546 skipping to change at line 659
port, i.e. the port selection at the destination side. port, i.e. the port selection at the destination side.
- GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid - GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid
failure notification. failure notification.
Note also some other key differences between MPLS-TE and GMPLS: Note also some other key differences between MPLS-TE and GMPLS:
- For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP - For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP
can be performed only in discrete units. can be performed only in discrete units.
E. Mannie et. al. Internet-Draft September 2002 10
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
- It is expected to have (much) fewer labels on TDM, LSC or FSC - It is expected to have (much) fewer labels on TDM, LSC or FSC
links than on PSC or L2SC links, because the former are physical links than on PSC or L2SC links, because the former are physical
labels instead of logical labels. labels instead of logical labels.
4. Routing and addressing model 4. Routing and addressing model
GMPLS is based on the IP routing and addressing models. This assumes GMPLS is based on the IP routing and addressing models. This assumes
that IPv4 and/or IPv6 addresses are used to identify interfaces and that IPv4 and/or IPv6 addresses are used to identify interfaces and
that traditional (distributed) IP routing protocols are also reused. that traditional (distributed) IP routing protocols are also reused.
Indeed, the discovery of the topology and the resource state of all Indeed, the discovery of the topology and the resource state of all
skipping to change at line 572 skipping to change at line 682
neighbors (i.e. IGP-learnt neighbors) may not be anymore data-plane neighbors (i.e. IGP-learnt neighbors) may not be anymore data-plane
neighbors, hence mechanisms like LMP are needed to associate TE neighbors, hence mechanisms like LMP are needed to associate TE
links with neighboring nodes. links with neighboring nodes.
IP addresses are not used only to identify interfaces of IP hosts IP addresses are not used only to identify interfaces of IP hosts
and routers, but more generally to identify any PSC and non-PSC and routers, but more generally to identify any PSC and non-PSC
interfaces. Similarly, IP routing protocols are used to find routes interfaces. Similarly, IP routing protocols are used to find routes
for IP datagrams with a SPF algorithm, and are also used to find for IP datagrams with a SPF algorithm, and are also used to find
routes for non-PSC circuits by using a CSPF algorithm. routes for non-PSC circuits by using a CSPF algorithm.
E. Mannie et. al. Internet-Draft February 2003 13
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
However, some additional mechanisms are needed to increase the However, some additional mechanisms are needed to increase the
scalability of these models and to deal with specific traffic scalability of these models and to deal with specific traffic
engineering requirements of non-PSC layers. These mechanisms will be engineering requirements of non-PSC layers. These mechanisms will be
introduced in the following. introduced in the following.
Re-using existing IP routing protocols allows for non-PSC layers to Re-using existing IP routing protocols allows for non-PSC layers to
take advantages of all the valuable developments that took place take advantages of all the valuable developments that took place
since years for IP routing, in particular in the context of intra- since years for IP routing, in particular in the context of intra-
domain routing (link-state routing) and inter-domain routing (policy domain routing (link-state routing) and inter-domain routing (policy
routing). routing).
skipping to change at line 603 skipping to change at line 716
BGP in a non-PSC context. Extensions for BGP traffic engineering BGP in a non-PSC context. Extensions for BGP traffic engineering
(BGP-TE) in the context of non-PSC layers are left for further (BGP-TE) in the context of non-PSC layers are left for further
study. study.
Each AS can be subdivided in different routing domains, and each can Each AS can be subdivided in different routing domains, and each can
run a different intra-domain routing protocol. In turn, each run a different intra-domain routing protocol. In turn, each
routing-domain can be divided in areas. routing-domain can be divided in areas.
A routing domain is made of GMPLS enabled nodes (i.e. a network A routing domain is made of GMPLS enabled nodes (i.e. a network
device including a GMPLS entity). These nodes can be either edge device including a GMPLS entity). These nodes can be either edge
E. Mannie et. al. Internet-Draft September 2002 11
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
nodes (i.e. hosts, ingress LSRs or egress LSRs), or internal LSRs. nodes (i.e. hosts, ingress LSRs or egress LSRs), or internal LSRs.
An example of non-PSC host is an SDH/SONET Terminal Multiplexer An example of non-PSC host is an SDH/SONET Terminal Multiplexer
(TM). Another example is an SDH/SONET interface card within an IP (TM). Another example is an SDH/SONET interface card within an IP
router or ATM switch. router or ATM switch.
Note that traffic engineering in the intra-domain requires the use Note that traffic engineering in the intra-domain requires the use
of link-state routing protocols like OSPF or IS-IS. of link-state routing protocols like OSPF or IS-IS.
GMPLS defines extensions to these protocols. These extensions are GMPLS defines extensions to these protocols. These extensions are
needed to disseminate specific TDM, LSC and FSC static and dynamic needed to disseminate specific TDM, LSC and FSC static and dynamic
skipping to change at line 628 skipping to change at line 737
intra-area traffic engineering. However, inter-area traffic intra-area traffic engineering. However, inter-area traffic
engineering is also under investigation. engineering is also under investigation.
4.1. Addressing of PSC and non-PSC layers 4.1. Addressing of PSC and non-PSC layers
The fact that IPv4 and/or IPv6 addresses are used doesn't imply at The fact that IPv4 and/or IPv6 addresses are used doesn't imply at
all that they should be allocated in the same addressing space than all that they should be allocated in the same addressing space than
public IPv4 and/or IPv6 addresses used for the Internet. Private IP public IPv4 and/or IPv6 addresses used for the Internet. Private IP
addresses can be used if they don't require to be exchanged with any addresses can be used if they don't require to be exchanged with any
other operator, public IP addresses are otherwise required. Of other operator, public IP addresses are otherwise required. Of
E. Mannie et. al. Internet-Draft February 2003 14
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
course, if an integrated model is used, two layers could share the course, if an integrated model is used, two layers could share the
same addressing space. same addressing space.
Note that there is a benefit of using public IPv4 and/or IPv6 Note that there is a benefit of using public IPv4 and/or IPv6
Internet addresses for non-PSC layers if an integrated model with Internet addresses for non-PSC layers if an integrated model with
the IP layer is foreseen. the IP layer is foreseen.
If we consider the scalability enhancements proposed in the next If we consider the scalability enhancements proposed in the next
section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing
spaces are both more than sufficient to accommodate any non-PSC spaces are both more than sufficient to accommodate any non-PSC
skipping to change at line 662 skipping to change at line 775
routing adjacency, and to advertise and to maintain link states for routing adjacency, and to advertise and to maintain link states for
each of these links. For that purpose, GMPLS enhances the MPLS each of these links. For that purpose, GMPLS enhances the MPLS
routing and addressing models to increase their scalability. routing and addressing models to increase their scalability.
Two optional mechanisms can be used to increase the scalability of Two optional mechanisms can be used to increase the scalability of
the addressing and the routing: unnumbered links and link bundling. the addressing and the routing: unnumbered links and link bundling.
These two mechanisms can also be combined. They require extensions These two mechanisms can also be combined. They require extensions
to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE) to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE)
protocols. protocols.
E. Mannie et. al. Internet-Draft September 2002 12
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
4.3. TE Extensions to IP routing protocols 4.3. TE Extensions to IP routing protocols
Traditionally, a TE link is advertised as an adjunct to a "regular" Traditionally, a TE link is advertised as an adjunct to a "regular"
OSPF or IS-IS link, i.e., an adjacency is brought up on the link, OSPF or IS-IS link, i.e., an adjacency is brought up on the link,
and when the link is up, both the regular IGP properties of the link and when the link is up, both the regular IGP properties of the link
(basically, the SPF metric) and the TE properties of the link are (basically, the SPF metric) and the TE properties of the link are
then advertised. then advertised.
However, GMPLS challenges this notion in three ways: However, GMPLS challenges this notion in three ways:
- First, links that are non-PSC may yet have TE properties; however, - First, links that are non-PSC may yet have TE properties; however,
an OSPF adjacency could not be brought up directly on such links. an OSPF adjacency could not be brought up directly on such links.
- Second, an LSP can be advertised as a point-to-point TE link in - Second, an LSP can be advertised as a point-to-point TE link in
the routing protocol, i.e. as a Forwarding Adjacency (FA); thus, an the routing protocol, i.e. as a Forwarding Adjacency (FA); thus, an
advertised TE link need no longer be between two OSPF direct advertised TE link need no longer be between two OSPF direct
neighbors. Forwarding Adjacencies (FA) are further described in a neighbors. Forwarding Adjacencies (FA) are further described in a
separate section. separate section.
E. Mannie et. al. Internet-Draft February 2003 15
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
- Third, a number of links may be advertised as a single TE link - Third, a number of links may be advertised as a single TE link
(e.g. for improved scalability), so again, there is no longer a one- (e.g. for improved scalability), so again, there is no longer a one-
to-one association of a regular adjacency and a TE link. to-one association of a regular adjacency and a TE link.
Thus we have a more general notion of a TE link. A TE link is a Thus we have a more general notion of a TE link. A TE link is a
logical link that has TE properties, some of which may be configured logical link that has TE properties, some of which may be configured
on the advertising LSR, others which may be obtained from other LSRs on the advertising LSR, others which may be obtained from other LSRs
by means of some protocol, and yet others which may be deduced from by means of some protocol, and yet others which may be deduced from
the component(s) of the TE link. the component(s) of the TE link.
skipping to change at line 718 skipping to change at line 831
protection can be elegantly combined with bundling. Protection and protection can be elegantly combined with bundling. Protection and
restoration are mainly generic mechanisms also applicable to MPLS. restoration are mainly generic mechanisms also applicable to MPLS.
It is expected that they will first be developed for MPLS and later It is expected that they will first be developed for MPLS and later
on generalized to GMPLS. on generalized to GMPLS.
A TE link between a pair of LSRs doesn't imply the existence of an A TE link between a pair of LSRs doesn't imply the existence of an
IGP adjacency between these LSRs. A TE link must also have some IGP adjacency between these LSRs. A TE link must also have some
means by which the advertising LSR can know of its liveness (e.g. by means by which the advertising LSR can know of its liveness (e.g. by
using LMP hellos). When an LSR knows that a TE link is up, and can using LMP hellos). When an LSR knows that a TE link is up, and can
determine the TE link's TE properties, the LSR may then advertise determine the TE link's TE properties, the LSR may then advertise
E. Mannie et. al. Internet-Draft September 2002 13
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE
objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF
or ISIS adjacencies are established "control channels". or ISIS adjacencies are established "control channels".
5. Unnumbered links 5. Unnumbered links
Unnumbered links (or interfaces) are links (or interfaces) that do Unnumbered links (or interfaces) are links (or interfaces) that do
not have IP addresses. Using such links involves two capabilities: not have IP addresses. Using such links involves two capabilities:
the ability to specify unnumbered links in MPLS TE signaling, and the ability to specify unnumbered links in MPLS TE signaling, and
the ability to carry (TE) information about unnumbered links in IGP the ability to carry (TE) information about unnumbered links in IGP
skipping to change at line 743 skipping to change at line 852
A. The ability to specify unnumbered links in MPLS TE signaling A. The ability to specify unnumbered links in MPLS TE signaling
requires extensions to RSVP-TE and CR-LDP. The MPLS-TE signaling requires extensions to RSVP-TE and CR-LDP. The MPLS-TE signaling
doesn't provide support for unnumbered links, because it doesnÆt doesn't provide support for unnumbered links, because it doesnÆt
provide a way to indicate an unnumbered link in its Explicit Route provide a way to indicate an unnumbered link in its Explicit Route
Object/TLV and in its Record Route Object (there is no such TLV Object/TLV and in its Record Route Object (there is no such TLV
for CR-LDP). GMPLS defines simple extensions to indicate an for CR-LDP). GMPLS defines simple extensions to indicate an
unnumbered link in these two Objects/TLVs, using a new Unnumbered unnumbered link in these two Objects/TLVs, using a new Unnumbered
Interface ID sub-object/sub-TLV. Interface ID sub-object/sub-TLV.
E. Mannie et. al. Internet-Draft February 2003 16
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Since unnumbered links are not identified by an IP address, then Since unnumbered links are not identified by an IP address, then
for the purpose of MPLS TE each end need some other identifier, for the purpose of MPLS TE each end need some other identifier,
local to the LSR to which the link belongs. LSRs at the two end local to the LSR to which the link belongs. LSRs at the two end
points of an unnumbered link exchange with each other the points of an unnumbered link exchange with each other the
identifiers they assign to the link. Exchanging the identifiers identifiers they assign to the link. Exchanging the identifiers
may be accomplished by configuration, by means of a protocol such may be accomplished by configuration, by means of a protocol such
as LMP ([LMP]), by means of RSVP/CR-LDP (especially in the case as LMP ([LMP]), by means of RSVP/CR-LDP (especially in the case
where a link is a Forwarding Adjacency, see below), or by means of where a link is a Forwarding Adjacency, see below), or by means of
IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]).
skipping to change at line 772 skipping to change at line 884
The new Unnumbered Interface ID sub-object/sub-TLV for the ER The new Unnumbered Interface ID sub-object/sub-TLV for the ER
Object/TLV contains the Router ID of the LSR at the upstream end Object/TLV contains the Router ID of the LSR at the upstream end
of the unnumbered link and the outgoing interface identifier or of the unnumbered link and the outgoing interface identifier or
the link local identifier with respect to that upstream LSR. the link local identifier with respect to that upstream LSR.
The new Unnumbered Interface ID sub-object for the RR Object The new Unnumbered Interface ID sub-object for the RR Object
contains the outgoing interface identifier with respect to the LSR contains the outgoing interface identifier with respect to the LSR
that adds it in the RR Object. that adds it in the RR Object.
E. Mannie et. al. Internet-Draft September 2002 14
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
B. The ability to carry (TE) information about unnumbered links in B. The ability to carry (TE) information about unnumbered links in
IGP TE extensions requires new sub-TLVs for the extended IS IGP TE extensions requires new sub-TLVs for the extended IS
reachability TLV defined in ISIS-TE and for the TE LSA (which is reachability TLV defined in ISIS-TE and for the TE LSA (which is
an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub-TLV an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub-TLV
and a Link Remote Identifier sub-TLV are defined. and a Link Remote Identifier sub-TLV are defined.
5.1. Unnumbered Forwarding Adjacencies 5.1. Unnumbered Forwarding Adjacencies
If an LSR that originates an LSP advertises this LSP as an If an LSR that originates an LSP advertises this LSP as an
unnumbered FA in IS-IS or OSPF, or the LSR uses this FA as an unnumbered FA in IS-IS or OSPF, or the LSR uses this FA as an
skipping to change at line 798 skipping to change at line 907
Signaling has been enhanced to carry the Interface ID of a FA in the Signaling has been enhanced to carry the Interface ID of a FA in the
new LSP Tunnel Interface ID object/TLV. This object/TLV contains the new LSP Tunnel Interface ID object/TLV. This object/TLV contains the
Router ID of the LSR that generates it, and the Interface ID. It is Router ID of the LSR that generates it, and the Interface ID. It is
called the Forward Interface ID when it appears in a Path/REQUEST called the Forward Interface ID when it appears in a Path/REQUEST
message, and it is called the Reverse Interface ID when it appears message, and it is called the Reverse Interface ID when it appears
in the Resv/MAPPING message. in the Resv/MAPPING message.
6. Link bundling 6. Link bundling
E. Mannie et. al. Internet-Draft February 2003 17
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
The concept of link bundling is essential in certain networks The concept of link bundling is essential in certain networks
employing the GMPLS control plane as is defined in [BUNDLE]. A employing the GMPLS control plane as is defined in [BUNDLE]. A
typical example is an optical meshed network where adjacent optical typical example is an optical meshed network where adjacent optical
cross-connects (LSRs) are connected by several hundreds of parallel cross-connects (LSRs) are connected by several hundreds of parallel
wavelengths. In this network, consider the application of link state wavelengths. In this network, consider the application of link state
routing protocols, like OSPF or IS-IS, with suitable extensions for routing protocols, like OSPF or IS-IS, with suitable extensions for
resource discovery and dynamic route computation. Each wavelength resource discovery and dynamic route computation. Each wavelength
must be advertised separately in order to be used, except if link must be advertised separately in order to be used, except if link
bundling is used. bundling is used.
skipping to change at line 827 skipping to change at line 939
unambiguously identify the appropriate resources used by an LSP. unambiguously identify the appropriate resources used by an LSP.
The purpose of link bundling is to improve routing scalability by The purpose of link bundling is to improve routing scalability by
reducing the amount of information that has to be handled by OSPF reducing the amount of information that has to be handled by OSPF
and/or IS-IS. This reduction is accomplished by performing and/or IS-IS. This reduction is accomplished by performing
information aggregation/abstraction. As with any other information information aggregation/abstraction. As with any other information
aggregation/abstraction, this results in losing some of the aggregation/abstraction, this results in losing some of the
information. To limit the amount of losses one need to restrict the information. To limit the amount of losses one need to restrict the
type of the information that can be aggregated/abstracted. type of the information that can be aggregated/abstracted.
E. Mannie et. al. Internet-Draft September 2002 15
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
6.1. Restrictions on bundling 6.1. Restrictions on bundling
The following restrictions are required for bundling links. All The following restrictions are required for bundling links. All
component links in a bundle must begin and end on the same pair of component links in a bundle must begin and end on the same pair of
LSRs; and share some common characteristics or properties defined in LSRs; and share some common characteristics or properties defined in
[OSPF-TE] and [ISIS-TE], i.e. they must have the same: [OSPF-TE] and [ISIS-TE], i.e. they must have the same:
- Link Type (i.e. point-to-point or multi-access), - Link Type (i.e. point-to-point or multi-access),
- TE Metric (i.e. an administrative cost), - TE Metric (i.e. an administrative cost),
- Set of Resource Classes at each end of the links (i.e. colors). - Set of Resource Classes at each end of the links (i.e. colors).
skipping to change at line 855 skipping to change at line 964
6.2. Routing considerations for bundling 6.2. Routing considerations for bundling
A bundled link is just another kind of TE link such as those defined A bundled link is just another kind of TE link such as those defined
by [GMPLS-ROUTING]. The liveness of the bundled link is determined by [GMPLS-ROUTING]. The liveness of the bundled link is determined
by the liveness of each its component links, a bundled link is alive by the liveness of each its component links, a bundled link is alive
when at least one of its component links is alive. The liveness of a when at least one of its component links is alive. The liveness of a
component link can be determined by any of several means: IS-IS or component link can be determined by any of several means: IS-IS or
OSPF hellos over the component link, or RSVP Hello (hop local), or OSPF hellos over the component link, or RSVP Hello (hop local), or
LMP hellos (link local), or from layer 1 or layer 2 indications. LMP hellos (link local), or from layer 1 or layer 2 indications.
E. Mannie et. al. Internet-Draft February 2003 18
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Note that according to the RSVP-TE Tunnel specification the RSVP Note that according to the RSVP-TE Tunnel specification the RSVP
Hello mechanism is intended to be used when notification of link Hello mechanism is intended to be used when notification of link
layer failures is not available and unnumbered links are not used, layer failures is not available and unnumbered links are not used,
or when the failure detection mechanisms provided by the link layer or when the failure detection mechanisms provided by the link layer
are not sufficient for timely node failure detection. are not sufficient for timely node failure detection.
Once a bundled link is determined to be alive, it can be advertised Once a bundled link is determined to be alive, it can be advertised
as a TE link and the TE information can be flooded. If IS-IS/OSPF as a TE link and the TE information can be flooded. If IS-IS/OSPF
hellos are run over the component links, IS-IS/OSPF flooding can be hellos are run over the component links, IS-IS/OSPF flooding can be
restricted to just one of the component links. restricted to just one of the component links.
skipping to change at line 883 skipping to change at line 995
Forming a bundled link consist in aggregating the identical TE Forming a bundled link consist in aggregating the identical TE
parameters of each individual component link to produce aggregated parameters of each individual component link to produce aggregated
TE parameters. A TE link as defined by [GMPLS-ROUTING] has many TE parameters. A TE link as defined by [GMPLS-ROUTING] has many
parameters, adequate aggregation rules must be defined for each one. parameters, adequate aggregation rules must be defined for each one.
Some parameters can be sums of component characteristics such as the Some parameters can be sums of component characteristics such as the
unreserved bandwidth and the maximum reservable bandwidth. Bandwidth unreserved bandwidth and the maximum reservable bandwidth. Bandwidth
information is an important part of a bundle advertisement and it information is an important part of a bundle advertisement and it
must be clearly defined since an abstraction is done. must be clearly defined since an abstraction is done.
E. Mannie et. al. Internet-Draft September 2002 16
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
A GMPLS node with bundled links must apply admission control on a A GMPLS node with bundled links must apply admission control on a
per-component link basis. per-component link basis.
6.3. Signaling considerations 6.3. Signaling considerations
Typically, an LSP's explicit route (e.g. contained in an explicit Typically, an LSP's explicit route (e.g. contained in an explicit
route TLV/Object) will choose the bundled link to be used for the route TLV/Object) will choose the bundled link to be used for the
LSP, but not the component link(s), since information about the LSP, but not the component link(s), since information about the
bundled link is flooded, but information about the component links bundled link is flooded, but information about the component links
is not. is not.
skipping to change at line 912 skipping to change at line 1021
are possible. are possible.
6.3.1. Mechanism 1: Implicit Indication 6.3.1. Mechanism 1: Implicit Indication
This mechanism requires that each component link has a dedicated This mechanism requires that each component link has a dedicated
signaling channel (e.g. the link is a Sonet/SDH link using the DCC signaling channel (e.g. the link is a Sonet/SDH link using the DCC
for in-band signaling). The upstream node tells the receiver which for in-band signaling). The upstream node tells the receiver which
component link to use by sending the message over the chosen component link to use by sending the message over the chosen
component link's dedicated signaling channel. Note that this component link's dedicated signaling channel. Note that this
signaling channel can be in-band or out-of-band. In this last case, signaling channel can be in-band or out-of-band. In this last case,
E. Mannie et. al. Internet-Draft February 2003 19
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
the association between the signaling channel and that component the association between the signaling channel and that component
link need to be explicitly configured. link need to be explicitly configured.
6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID 6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID
This mechanism requires that the component link has a unique remote This mechanism requires that the component link has a unique remote
IP address. The upstream node indicates the choice of the component IP address. The upstream node indicates the choice of the component
link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying
either an IPv4 or an IPv6 address in the Path/Label Request message either an IPv4 or an IPv6 address in the Path/Label Request message
[RSVP-TE-GMPLS] [CR-LDP-GMPLS]. For a bi-directional LSP, a component [RSVP-TE-GMPLS] [CR-LDP-GMPLS]. For a bi-directional LSP, a
link is provided for each direction by the upstream node. component link is provided for each direction by the upstream node.
This mechanism does not require each component link to have its own This mechanism does not require each component link to have its own
control channel. In fact, it doesn't even require the whole control channel. In fact, it doesn't even require the whole
(bundled) link to have its own control channel. (bundled) link to have its own control channel.
6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID 6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID
With this mechanism, each component link that is unnumbered is With this mechanism, each component link that is unnumbered is
assigned a unique Interface Identifier (32 bits value). The upstream assigned a unique Interface Identifier (32 bits value). The upstream
node indicates the choice of the component link by including a new node indicates the choice of the component link by including a new
IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message
[RSVP-TE-GMPLS] [CR-LDP-GMPLS]. [RSVP-TE-GMPLS] [CR-LDP-GMPLS].
This object/TLV carries the component interface ID in the downstream This object/TLV carries the component interface ID in the downstream
direction for a unidirectional LSP, and in addition the component direction for a unidirectional LSP, and in addition the component
interface ID in the upstream direction for a bi-directional LSP. interface ID in the upstream direction for a bi-directional LSP.
E. Mannie et. al. Internet-Draft September 2002 17
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
The two LSRs at each end of the bundled link exchange these The two LSRs at each end of the bundled link exchange these
identifiers. Exchanging the identifiers may be accomplished by identifiers. Exchanging the identifiers may be accomplished by
configuration, by means of a protocol such as LMP (preferred configuration, by means of a protocol such as LMP (preferred
solution), by means of RSVP/CR-LDP (especially in the case where a solution), by means of RSVP/CR-LDP (especially in the case where a
component link is a Forwarding Adjacency), or by means of IS-IS or component link is a Forwarding Adjacency), or by means of IS-IS or
OSPF extensions. OSPF extensions.
This mechanism does not require each component link to have its own This mechanism does not require each component link to have its own
control channel. In fact, it doesn't even require the whole control channel. In fact, it doesn't even require the whole
(bundled) link to have its own control channel. (bundled) link to have its own control channel.
skipping to change at line 969 skipping to change at line 1079
EROs that traverse the bundled link. Furthermore, unnumbered EROs that traverse the bundled link. Furthermore, unnumbered
Interface Identifiers for all unnumbered outgoing links of a given Interface Identifiers for all unnumbered outgoing links of a given
LSR (whether component links, Forwarding Adjacencies or bundled LSR (whether component links, Forwarding Adjacencies or bundled
links) must be unique in the context of that LSR. links) must be unique in the context of that LSR.
6.5. Forming bundled links 6.5. Forming bundled links
The generic rule for bundling component links is to place those The generic rule for bundling component links is to place those
links that are correlated in some manner in the same bundle. If links that are correlated in some manner in the same bundle. If
links may be correlated based on multiple properties then the links may be correlated based on multiple properties then the
E. Mannie et. al. Internet-Draft February 2003 20
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
bundling may be applied sequentially based on these properties. For bundling may be applied sequentially based on these properties. For
instance, links may be first grouped based on the first property. instance, links may be first grouped based on the first property.
Each of these groups may be then divided into smaller groups based Each of these groups may be then divided into smaller groups based
on the second property and so on. The main principle followed in on the second property and so on. The main principle followed in
this process is that the properties of the resulting bundles should this process is that the properties of the resulting bundles should
be concisely summarizable. Link bundling may be done automatically be concisely summarizable. Link bundling may be done automatically
or by configuration. Automatic link bundling can apply bundling or by configuration. Automatic link bundling can apply bundling
rules sequentially to produce bundles. rules sequentially to produce bundles.
For instance, the first property on which component links may be For instance, the first property on which component links may be
skipping to change at line 998 skipping to change at line 1112
link belonging to an SRLG that some link in the primary path belongs link belonging to an SRLG that some link in the primary path belongs
to. Thus, the rule to be followed is to group links belonging to to. Thus, the rule to be followed is to group links belonging to
exactly the same set of SRLGs. exactly the same set of SRLGs.
This type of sequential sub-division may result in a number of This type of sequential sub-division may result in a number of
bundles between two adjacent nodes. In practice, however, the link bundles between two adjacent nodes. In practice, however, the link
properties may not be very heterogeneous among component links properties may not be very heterogeneous among component links
between two adjacent nodes. Thus, the number of bundles in practice between two adjacent nodes. Thus, the number of bundles in practice
may not be large. may not be large.
E. Mannie et. al. Internet-Draft September 2002 18
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
7. Relationship with the UNI 7. Relationship with the UNI
The interface between an edge GMPLS node and a GMPLS LSR on the The interface between an edge GMPLS node and a GMPLS LSR on the
network side may be referred to as a User to Network Interface network side may be referred to as a User to Network Interface
(UNI), while the interface between two network side LSRs may be (UNI), while the interface between two network side LSRs may be
referred to as a Network to Network Interface (NNI). referred to as a Network to Network Interface (NNI).
GMPLS does not specify separately a UNI and an NNI. Edge nodes are GMPLS does not specify separately a UNI and an NNI. Edge nodes are
connected to LSRs on the network side, and these LSRs are in turn connected to LSRs on the network side, and these LSRs are in turn
connected between them. Of course, the behavior of an edge node is connected between them. Of course, the behavior of an edge node is
skipping to change at line 1026 skipping to change at line 1137
Conceptually, a difference between UNI and NNI make sense either if Conceptually, a difference between UNI and NNI make sense either if
both interface uses completely different protocols, or if they use both interface uses completely different protocols, or if they use
the same protocols but with some outstanding differences. In the the same protocols but with some outstanding differences. In the
first case, separate protocols are often defined successively, with first case, separate protocols are often defined successively, with
more or less success. more or less success.
The GMPLS approach consisted in building a consistent model from day The GMPLS approach consisted in building a consistent model from day
one, considering both the UNI and NNI interfaces at the same time. one, considering both the UNI and NNI interfaces at the same time.
For that purpose a very few specific UNI particularities have been For that purpose a very few specific UNI particularities have been
ignored in a first time. GMPLS has been enhanced to support such ignored in a first time. GMPLS has been enhanced to support such
E. Mannie et. al. Internet-Draft February 2003 21
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
particularities at the UNI by some other standardization bodies (see particularities at the UNI by some other standardization bodies (see
hereafter). hereafter).
7.1. Relationship with the OIF UNI 7.1. Relationship with the OIF UNI
This section is only given for reference to the OIF work related to This section is only given for reference to the OIF work related to
GMPLS. The current OIF UNI specification [OIF-UNI] defines an GMPLS. The current OIF UNI specification [OIF-UNI] defines an
interface between a client SDH/SONET equipment and an SDH/SONET interface between a client SDH/SONET equipment and an SDH/SONET
network, each belonging to a distinct administrative authority. It network, each belonging to a distinct administrative authority. It
is designed for an overlay model. The OIF UNI defines additional is designed for an overlay model. The OIF UNI defines additional
skipping to change at line 1055 skipping to change at line 1170
Since the current OIF UNI interface does not cover photonic Since the current OIF UNI interface does not cover photonic
networks, G.709 Digital Wrapper, etc, it is from that perspective a networks, G.709 Digital Wrapper, etc, it is from that perspective a
subset of the GMPLS Architecture at the UNI. subset of the GMPLS Architecture at the UNI.
7.2. Reachability across the UNI 7.2. Reachability across the UNI
This section discusses the selection of an explicit route by an edge This section discusses the selection of an explicit route by an edge
node. The selection of the first LSR by an edge node connected to node. The selection of the first LSR by an edge node connected to
multiple LSRs is part of that problem. multiple LSRs is part of that problem.
E. Mannie et. al. Internet-Draft September 2002 19
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
An edge node (host or LSR) can participate more or less deeply in An edge node (host or LSR) can participate more or less deeply in
the GMPLS routing. Four different routing models can be supported at the GMPLS routing. Four different routing models can be supported at
the UNI: configuration based, partial peering, silent listening and the UNI: configuration based, partial peering, silent listening and
full peering. full peering.
- Configuration based: this routing model requires the manual or - Configuration based: this routing model requires the manual or
automatic configuration of an edge node with a list of neighbor LSRs automatic configuration of an edge node with a list of neighbor LSRs
sorted by preference order. Automatic configuration can be achieved sorted by preference order. Automatic configuration can be achieved
using DHCP for instance. No routing information is exchanged at the using DHCP for instance. No routing information is exchanged at the
UNI, except maybe the ordered list of LSRs. The only routing UNI, except maybe the ordered list of LSRs. The only routing
skipping to change at line 1083 skipping to change at line 1195
- Partial peering: limited routing information (mainly reachability) - Partial peering: limited routing information (mainly reachability)
can be exchanged across the UNI using some extensions in the can be exchanged across the UNI using some extensions in the
signaling plane. The reachability information exchanged at the UNI signaling plane. The reachability information exchanged at the UNI
may be used to initiate edge node specific routing decision over the may be used to initiate edge node specific routing decision over the
network. GMPLS does not have any capability to support this model network. GMPLS does not have any capability to support this model
today. today.
- Silent listening: the edge node can silently listen to routing - Silent listening: the edge node can silently listen to routing
protocols and take routing decisions based on the information protocols and take routing decisions based on the information
obtained. An edge node receives the full routing information, obtained. An edge node receives the full routing information,
E. Mannie et. al. Internet-Draft February 2003 22
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
including traffic engineering extensions. One LSR should forward including traffic engineering extensions. One LSR should forward
transparently all routing pdus to the edge node. An edge node can transparently all routing pdus to the edge node. An edge node can
now compute a complete explicit route taking into consideration all now compute a complete explicit route taking into consideration all
the end-to-end routing information. GMPLS does not preclude this the end-to-end routing information. GMPLS does not preclude this
model. model.
- Full peering: In addition to silent listening, the edge node - Full peering: In addition to silent listening, the edge node
participates within the routing, establish adjacencies with its participates within the routing, establish adjacencies with its
neighbors and advertises LSAs. This is useful only if there are neighbors and advertises LSAs. This is useful only if there are
benefits for edge nodes to advertise themselves traffic engineering benefits for edge nodes to advertise themselves traffic engineering
skipping to change at line 1111 skipping to change at line 1227
bundled links for routing purposes. Furthermore, to enable bundled links for routing purposes. Furthermore, to enable
communication between nodes for routing, signaling, and link communication between nodes for routing, signaling, and link
management, control channels must be established between a node management, control channels must be established between a node
pair. pair.
Link management is a collection of useful procedures between Link management is a collection of useful procedures between
adjacent nodes that provide local services such as control channel adjacent nodes that provide local services such as control channel
management, link connectivity verification, link property management, link connectivity verification, link property
correlation, and fault management. The Link Management Protocol correlation, and fault management. The Link Management Protocol
(LMP) has been defined to fulfill these operations. LMP was (LMP) has been defined to fulfill these operations. LMP was
E. Mannie et. al. Internet-Draft September 2002 20
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
initiated in the context of GMPLS but is a generic toolbox that can initiated in the context of GMPLS but is a generic toolbox that can
be also used in other contexts. be also used in other contexts.
Control channel management and link property correlation are Control channel management and link property correlation are
mandatory procedures of LMP. Link connectivity verification and mandatory procedures of LMP. Link connectivity verification and
fault management are optional procedures. fault management are optional procedures.
8.1. Control channel and control channel management 8.1. Control channel and control channel management
LMP control channel management is used to establish and maintain LMP control channel management is used to establish and maintain
skipping to change at line 1141 skipping to change at line 1253
LMP capabilities. Multiple control channels may be active LMP capabilities. Multiple control channels may be active
simultaneously for each adjacency. A control channel can be either simultaneously for each adjacency. A control channel can be either
explicitly configured or automatically selected, however, LMP explicitly configured or automatically selected, however, LMP
currently assume that control channels are explicitly configured currently assume that control channels are explicitly configured
while the configuration of the control channel capabilities can be while the configuration of the control channel capabilities can be
dynamically negotiated. dynamically negotiated.
For the purposes of LMP, the exact implementation of the control For the purposes of LMP, the exact implementation of the control
channel is left unspecified. The control channel(s) between two channel is left unspecified. The control channel(s) between two
adjacent nodes is no longer required to use the same physical medium adjacent nodes is no longer required to use the same physical medium
E. Mannie et. al. Internet-Draft February 2003 23
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
as the data-bearing links between those nodes. For example, a as the data-bearing links between those nodes. For example, a
control channel could use a separate wavelength or fiber, an control channel could use a separate wavelength or fiber, an
Ethernet link, or an IP tunnel through a separate management Ethernet link, or an IP tunnel through a separate management
network. network.
A consequence of allowing the control channel(s) between two nodes A consequence of allowing the control channel(s) between two nodes
to be physically diverse from the associated data-bearing links is to be physically diverse from the associated data-bearing links is
that the health of a control channel does not necessarily correlate that the health of a control channel does not necessarily correlate
to the health of the data-bearing links, and vice-versa. Therefore, to the health of the data-bearing links, and vice-versa. Therefore,
new mechanisms have been developed in LMP to manage links, both in new mechanisms have been developed in LMP to manage links, both in
skipping to change at line 1170 skipping to change at line 1286
Each control channel individually negotiates its control channel Each control channel individually negotiates its control channel
parameters and maintains connectivity using a fast Hello protocol. parameters and maintains connectivity using a fast Hello protocol.
The latter is required if lower-level mechanisms are not available The latter is required if lower-level mechanisms are not available
to detect link failures. to detect link failures.
The Hello protocol of LMP is intended to be a lightweight keep-alive The Hello protocol of LMP is intended to be a lightweight keep-alive
mechanism that will react to control channel failures rapidly so mechanism that will react to control channel failures rapidly so
that IGP Hellos are not lost and the associated link-state that IGP Hellos are not lost and the associated link-state
adjacencies are not removed unnecessarily. adjacencies are not removed unnecessarily.
E. Mannie et. al. Internet-Draft September 2002 21
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
The Hello protocol consists of two phases: a negotiation phase and a The Hello protocol consists of two phases: a negotiation phase and a
keep-alive phase. The negotiation phase allows negotiation of some keep-alive phase. The negotiation phase allows negotiation of some
basic Hello protocol parameters, like the Hello frequency. The keep- basic Hello protocol parameters, like the Hello frequency. The keep-
alive phase consists of a fast lightweight bi-directional Hello alive phase consists of a fast lightweight bi-directional Hello
message exchange. message exchange.
If a group of control channels share a common node pair and support If a group of control channels share a common node pair and support
the same LMP capabilities, then LMP control channel messages (except the same LMP capabilities, then LMP control channel messages (except
Configuration messages, and Hello) may be transmitted over any of Configuration messages, and Hello) may be transmitted over any of
the active control channels without coordination between the local the active control channels without coordination between the local
skipping to change at line 1199 skipping to change at line 1312
8.2. Link property correlation 8.2. Link property correlation
As part of LMP, a link property correlation exchange is defined. As part of LMP, a link property correlation exchange is defined.
The exchange is used to aggregate multiple data-bearing links (i.e. The exchange is used to aggregate multiple data-bearing links (i.e.
component links) into a bundled link and exchange, correlate, or component links) into a bundled link and exchange, correlate, or
change TE link parameters. The link property correlation exchange change TE link parameters. The link property correlation exchange
may be done at any time a link is up and not in the Verification may be done at any time a link is up and not in the Verification
process (see next section). process (see next section).
E. Mannie et. al. Internet-Draft February 2003 24
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
It allows for instance to add component links to a link bundle, It allows for instance to add component links to a link bundle,
change a link's protection mechanism, change port identifiers, or change a link's protection mechanism, change port identifiers, or
change component identifiers in a bundle. This mechanism is change component identifiers in a bundle. This mechanism is
supported by an exchange of link summary messages. supported by an exchange of link summary messages.
8.3. Link connectivity verification 8.3. Link connectivity verification
Link connectivity verification is an optional procedure that may be Link connectivity verification is an optional procedure that may be
used to verify the physical connectivity of data-bearing links as used to verify the physical connectivity of data-bearing links as
well as to exchange the link identifiers that are used in the GMPLS well as to exchange the link identifiers that are used in the GMPLS
skipping to change at line 1226 skipping to change at line 1342
The verification procedure consists of sending Test messages in-band The verification procedure consists of sending Test messages in-band
over the data-bearing links. This requires that the unallocated over the data-bearing links. This requires that the unallocated
links must be opaque; however, multiple degrees of opaqueness (e.g., links must be opaque; however, multiple degrees of opaqueness (e.g.,
examining overhead bytes, terminating the payload, etc.), and hence examining overhead bytes, terminating the payload, etc.), and hence
different mechanisms to transport the Test messages, are specified. different mechanisms to transport the Test messages, are specified.
Note that the Test message is the only LMP message that is Note that the Test message is the only LMP message that is
transmitted over the link, and that Hello messages continue to be transmitted over the link, and that Hello messages continue to be
exchanged over the control channel during the link verification exchanged over the control channel during the link verification
process. Data-bearing links are tested in the transmit direction as process. Data-bearing links are tested in the transmit direction as
E. Mannie et. al. Internet-Draft September 2002 22
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
they are unidirectional. As such, it is possible for LMP neighboring they are unidirectional. As such, it is possible for LMP neighboring
nodes to exchange the Test messages simultaneously in both nodes to exchange the Test messages simultaneously in both
directions. directions.
To initiate the link verification procedure, a node must first To initiate the link verification procedure, a node must first
notify the adjacent node that it will begin sending Test messages notify the adjacent node that it will begin sending Test messages
over a particular data-bearing link, or over the component links of over a particular data-bearing link, or over the component links of
a particular bundled link. The node must also indicate the number of a particular bundled link. The node must also indicate the number of
data-bearing links that are to be verified; the interval at which data-bearing links that are to be verified; the interval at which
the test messages will be sent; the encoding scheme, the transport the test messages will be sent; the encoding scheme, the transport
skipping to change at line 1256 skipping to change at line 1368
8.4. Fault management 8.4. Fault management
Fault management is an important requirement from the operational Fault management is an important requirement from the operational
point of view. Fault management includes usually: fault detection, point of view. Fault management includes usually: fault detection,
fault localization and fault notification. When a failure occurs and fault localization and fault notification. When a failure occurs and
is detected (fault detection), an operator needs to know exactly is detected (fault detection), an operator needs to know exactly
where it happened (fault localization) and a source node may need to where it happened (fault localization) and a source node may need to
be notified in order to take some actions (fault notification). be notified in order to take some actions (fault notification).
E. Mannie et. al. Internet-Draft February 2003 25
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Note that fault localization can also be used to support some Note that fault localization can also be used to support some
specific local protection/restoration mechanisms. specific local protection/restoration mechanisms.
In new technologies such as transparent photonic switching currently In new technologies such as transparent photonic switching currently
no method is defined to locate a fault, and the mechanism by which no method is defined to locate a fault, and the mechanism by which
the fault information is propagated must be sent "out of band" (via the fault information is propagated must be sent "out of band" (via
the control plane). the control plane).
LMP provides a fault localization procedure that can be used to LMP provides a fault localization procedure that can be used to
rapidly localize link failures, by notifying a fault up to the node rapidly localize link failures, by notifying a fault up to the node
skipping to change at line 1284 skipping to change at line 1399
has been localized, the signaling protocols can be used to initiate has been localized, the signaling protocols can be used to initiate
link or path protection/restoration procedures. link or path protection/restoration procedures.
8.5 LMP for DWDM Optical Line Systems (OLSs) 8.5 LMP for DWDM Optical Line Systems (OLSs)
In an all-optical environment, LMP focuses on peer communications In an all-optical environment, LMP focuses on peer communications
(e.g. OXC-to-OXC). A great deal of information about a link between (e.g. OXC-to-OXC). A great deal of information about a link between
two OXCs is known by the OLS (Optical Line System or WDM Terminal two OXCs is known by the OLS (Optical Line System or WDM Terminal
multiplexer). Exposing this information to the control plane can multiplexer). Exposing this information to the control plane can
improve network usability by further reducing required manual improve network usability by further reducing required manual
E. Mannie et. al. Internet-Draft September 2002 23
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
configuration and also by greatly enhancing fault detection and configuration and also by greatly enhancing fault detection and
recovery. recovery.
LMP-WDM [LMP-WDM] defines extensions to LMP for use between and OXC LMP-WDM [LMP-WDM] defines extensions to LMP for use between and OXC
and an OLS. These extensions are intended to satisfy the Optical Link and an OLS. These extensions are intended to satisfy the Optical
Interface Requirements described in [OLI-REQ]. Link Interface Requirements described in [OLI-REQ].
Fault detection is particularly an issue when the network is using Fault detection is particularly an issue when the network is using
all-optical photonic switches (PXC). Once a connection is all-optical photonic switches (PXC). Once a connection is
established, PXCs have only limited visibility into the health of the established, PXCs have only limited visibility into the health of
connection. Even though the PXC is all-optical, long-haul OLSs the connection. Even though the PXC is all-optical, long-haul OLSs
typically terminate channels electrically and regenerate them typically terminate channels electrically and regenerate them
optically, which presents an opportunity to monitor the health of a optically, which presents an opportunity to monitor the health of a
channel between PXCs. LMP-WDM can then be used by the OLS to provide channel between PXCs. LMP-WDM can then be used by the OLS to provide
this information to the PXC. this information to the PXC.
In addition to the link information known to the OLS that is In addition to the link information known to the OLS that is
exchanged through LMP-WDM, some information known to the OXC may also exchanged through LMP-WDM, some information known to the OXC may
be exchanged with the OLS through LMP-WDM. This information is useful also be exchanged with the OLS through LMP-WDM. This information is
for alarm management and link monitoring (e.g. trace monitoring). useful for alarm management and link monitoring (e.g. trace
Alarm management is important because the administrative state of a monitoring). Alarm management is important because the
connection, known to the OXC (e.g. this information may be learned administrative state of a connection, known to the OXC (e.g. this
through the Admin Status object of GMPLS signaling [GMPLS]), can be information may be learned through the Admin Status object of GMPLS
used to suppress spurious alarms. For example, the OXC may know that signaling [GMPLS]), can be used to suppress spurious alarms. For
a connection is "up", "down", in a "testing" mode, or being deleted example, the OXC may know that a connection is "up", "down", in a
("deletion-in-progress"). The OXC can use this information to inhibit "testing" mode, or being deleted ("deletion-in-progress"). The OXC
alarm reporting from the OLS when a connection is "down", "testing",
or being deleted. E. Mannie et. al. Internet-Draft February 2003 26
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
can use this information to inhibit alarm reporting from the OLS
when a connection is "down", "testing", or being deleted.
It is important to note that an OXC may peer with one or more OLSs It is important to note that an OXC may peer with one or more OLSs
and an OLS may peer with one or more OXCs. Although there are many and an OLS may peer with one or more OXCs. Although there are many
similarities between an OXC-OXC LMP session and an OXC-OLS LMP similarities between an OXC-OXC LMP session and an OXC-OLS LMP
session, particularly for control management and link verification, session, particularly for control management and link verification,
there are some differences as well. These differences can primarily there are some differences as well. These differences can primarily
be attributed to the nature of an OXC-OLS link, and the purpose of be attributed to the nature of an OXC-OLS link, and the purpose of
OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the
basis for GMPLS signaling and routing at the optical layer. The basis for GMPLS signaling and routing at the optical layer. The
information exchanged over LMP-WDM sessions is used to augment information exchanged over LMP-WDM sessions is used to augment
knowledge about the links between OXCs. knowledge about the links between OXCs.
In order for the information exchanged over the OXC-OLS LMP sessions In order for the information exchanged over the OXC-OLS LMP sessions
to be used by the OXC-OXC session, the information must be to be used by the OXC-OXC session, the information must be
coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP sessions coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP
are run independently and must be maintained separately. One critical sessions are run independently and must be maintained separately.
requirement when running an OXC-OLS LMP session is the ability of the One critical requirement when running an OXC-OLS LMP session is the
OLS to make a data link transparent when not doing the verification ability of the OLS to make a data link transparent when not doing
procedure. This is because the same data link may be verified between the verification procedure. This is because the same data link may
OXC-OLS and between OXC-OXC. The verification procedure of LMP is be verified between OXC-OLS and between OXC-OXC. The verification
used to coordinate the Test procedure (and hence the procedure of LMP is used to coordinate the Test procedure (and hence
transparency/opaqueness of the data links). To maintain independence the transparency/opaqueness of the data links). To maintain
between the sessions, it must be possible for the LMP sessions to independence between the sessions, it must be possible for the LMP
come up in any order. In particular, it must be possible for an OXC- sessions to come up in any order. In particular, it must be possible
OXC LMP session to come up without an OXC-OLS LMP session being for an OXC-OXC LMP session to come up without an OXC-OLS LMP session
brought up, and vice-versa. being brought up, and vice-versa.
E. Mannie et. al. Internet-Draft September 2002 24
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
9. Generalized Signaling 9. Generalized Signaling
The GMPLS signaling extends certain base functions of the RSVP-TE The GMPLS signaling extends certain base functions of the RSVP-TE
and CR-LDP signaling and, in some cases, adds functionality. These and CR-LDP signaling and, in some cases, adds functionality. These
changes and additions impact basic LSP properties, how labels are changes and additions impact basic LSP properties, how labels are
requested and communicated, the unidirectional nature of LSPs, how requested and communicated, the unidirectional nature of LSPs, how
errors are propagated, and information provided for synchronizing errors are propagated, and information provided for synchronizing
the ingress and egress. the ingress and egress.
skipping to change at line 1371 skipping to change at line 1483
In addition, independent parts are available per technology: In addition, independent parts are available per technology:
1. GMPLS extensions for SONET and SDH control [SONETSDH-GMPLS]. 1. GMPLS extensions for SONET and SDH control [SONETSDH-GMPLS].
2. GMPLS extensions for G.709 control [G709-GMPLS]. 2. GMPLS extensions for G.709 control [G709-GMPLS].
The following MPLS profile expressed in terms of MPLS features The following MPLS profile expressed in terms of MPLS features
[RFC3031] applies to GMPLS: [RFC3031] applies to GMPLS:
- Downstream-on-demand label allocation and distribution. - Downstream-on-demand label allocation and distribution.
- Ingress initiated ordered control. - Ingress initiated ordered control.
E. Mannie et. al. Internet-Draft February 2003 27
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
- Liberal (typical), or conservative (could) label retention - Liberal (typical), or conservative (could) label retention
mode. mode.
- Request, traffic/data, or topology driven label allocation - Request, traffic/data, or topology driven label allocation
strategy. strategy.
- Explicit routing (typical), or hop-by-hop routing. - Explicit routing (typical), or hop-by-hop routing.
The GMPLS signaling defines the following new building blocks on the The GMPLS signaling defines the following new building blocks on the
top of MPLS-TE: top of MPLS-TE:
1. A new generic label request format. 1. A new generic label request format.
skipping to change at line 1398 skipping to change at line 1514
6. Bi-directional LSP establishment with contention 6. Bi-directional LSP establishment with contention
resolution. resolution.
7. Rapid failure notification extensions. 7. Rapid failure notification extensions.
8. Protection information currently focusing on link protection, 8. Protection information currently focusing on link protection,
plus primary and secondary LSP indication. plus primary and secondary LSP indication.
9. Explicit routing with explicit label control for a fine 9. Explicit routing with explicit label control for a fine
degree of control. degree of control.
10. Specific traffic parameters per technology. 10. Specific traffic parameters per technology.
11. LSP administrative status handling. 11. LSP administrative status handling.
E. Mannie et. al. Internet-Draft September 2002 25
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
These building blocks will be described in mode details in the These building blocks will be described in mode details in the
following. A complete specification can be found in the following. A complete specification can be found in the
corresponding documents. corresponding documents.
Note that GMPLS is highly generic and has many options. Only Note that GMPLS is highly generic and has many options. Only
building blocks 1, 2 and 10 are mandatory, and only within the building blocks 1, 2 and 10 are mandatory, and only within the
specific format that is needed. Typically building blocks 6 and 9 specific format that is needed. Typically building blocks 6 and 9
should be implemented. Building blocks 3, 4, 5, 7, 8 and 11 are should be implemented. Building blocks 3, 4, 5, 7, 8 and 11 are
optional. optional.
skipping to change at line 1428 skipping to change at line 1541
block 3 is only needed in the particular case of waveband switching. block 3 is only needed in the particular case of waveband switching.
A typical fiber switching network would implement building blocks: A typical fiber switching network would implement building blocks:
1, 2 (the generic format), 6, 7, 8, 9 and 11. 1, 2 (the generic format), 6, 7, 8, 9 and 11.
A typical MPLS-IP network would not implement any of these building A typical MPLS-IP network would not implement any of these building
blocks, since the absence of building block 1 would indicate regular blocks, since the absence of building block 1 would indicate regular
MPLS-IP. Note however that building block 1 and 8 can be used to MPLS-IP. Note however that building block 1 and 8 can be used to
signal MPLS-IP as well. In that case, the MPLS-IP network can signal MPLS-IP as well. In that case, the MPLS-IP network can
benefit from the link protection type (not available in CR-LDP, some benefit from the link protection type (not available in CR-LDP, some
E. Mannie et. al. Internet-Draft February 2003 28
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
very basic form being available in RSVP-TE). Building block 2 is very basic form being available in RSVP-TE). Building block 2 is
here a regular MPLS label and no new label format is required. here a regular MPLS label and no new label format is required.
GMPLS does not specify any profile for RSVP-TE and CR-LDP GMPLS does not specify any profile for RSVP-TE and CR-LDP
implementations that have to support GMPLS - except for what is implementations that have to support GMPLS - except for what is
directly related to GMPLS procedures. It is to the manufacturer to directly related to GMPLS procedures. It is to the manufacturer to
decide which are the optional elements and procedures of RSVP-TE and decide which are the optional elements and procedures of RSVP-TE and
CR-LDP that need to be implemented. Some optional MPLS-TE elements CR-LDP that need to be implemented. Some optional MPLS-TE elements
can be useful for TDM, LSC and FSC layers, for instance the setup can be useful for TDM, LSC and FSC layers, for instance the setup
and holding priorities that are inherited from MPLS-TE. and holding priorities that are inherited from MPLS-TE.
skipping to change at line 1456 skipping to change at line 1573
completed by the first/default LSR. completed by the first/default LSR.
The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC
object, or in the CR-LDP Traffic Parameters TLV. Specific parameters object, or in the CR-LDP Traffic Parameters TLV. Specific parameters
for a given technology are given in these traffic parameters, such for a given technology are given in these traffic parameters, such
as the type of signal, concatenation and/or transparency for a as the type of signal, concatenation and/or transparency for a
SDH/SONET LSP. For some other technology there be could just one SDH/SONET LSP. For some other technology there be could just one
bandwidth parameter indicating the bandwidth as a floating-point bandwidth parameter indicating the bandwidth as a floating-point
value. value.
E. Mannie et. al. Internet-Draft September 2002 26
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
The requested local protection per link may be requested using the The requested local protection per link may be requested using the
Protection Information Object/TLV. The end-to-end LSP protection is Protection Information Object/TLV. The end-to-end LSP protection is
for further study and is introduced LSP protection/restoration for further study and is introduced LSP protection/restoration
section (see after). section (see after).
If the LSP is a bi-directional LSP, an Upstream Label is also If the LSP is a bi-directional LSP, an Upstream Label is also
specified in the Path/Label Request message. This label will be the specified in the Path/Label Request message. This label will be the
one to use in the upstream direction. one to use in the upstream direction.
Additionally, a Suggested Label, a Label Set and a Waveband Label Additionally, a Suggested Label, a Label Set and a Waveband Label
skipping to change at line 1486 skipping to change at line 1600
In case of SDH/SONET virtual concatenation, a list of labels is In case of SDH/SONET virtual concatenation, a list of labels is
returned. Each label identifying one element of the virtual returned. Each label identifying one element of the virtual
concatenated signal. This limits virtual concatenation to remain concatenated signal. This limits virtual concatenation to remain
within a single (component) link. within a single (component) link.
In case of any type of SDH/SONET contiguous concatenation, only one In case of any type of SDH/SONET contiguous concatenation, only one
label is returned. That label is the lowest signal of the contiguous label is returned. That label is the lowest signal of the contiguous
concatenated signal (given an order specified in [SONETSDH-GMPLS]). concatenated signal (given an order specified in [SONETSDH-GMPLS]).
E. Mannie et. al. Internet-Draft February 2003 29
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
In case of SDH/SONET "multiplication", i.e. co-routing of circuits In case of SDH/SONET "multiplication", i.e. co-routing of circuits
of the same type but without concatenation but all belonging to the of the same type but without concatenation but all belonging to the
same LSP, the explicit ordered list of all signals that take part in same LSP, the explicit ordered list of all signals that take part in
the LSP is returned. the LSP is returned.
9.2. Generalized Label Request 9.2. Generalized Label Request
The Generalized Label Request is a new object/TLV to be added in an The Generalized Label Request is a new object/TLV to be added in an
RSVP-TE Path message instead of the regular Label Request, or in a RSVP-TE Path message instead of the regular Label Request, or in a
CR-LDP Request message in addition to the already existing TLVs. CR-LDP Request message in addition to the already existing TLVs.
skipping to change at line 1511 skipping to change at line 1628
Encoding Type, the Switching Type that must be used and the LSP Encoding Type, the Switching Type that must be used and the LSP
payload type called Generalized PID (G-PID). payload type called Generalized PID (G-PID).
The LSP Encoding Type indicates the encoding type that will be used The LSP Encoding Type indicates the encoding type that will be used
with the data associated with the LSP, i.e. the type of technology with the data associated with the LSP, i.e. the type of technology
being considered. For instance, it can be SDH, SONET, Ethernet, ANSI being considered. For instance, it can be SDH, SONET, Ethernet, ANSI
PDH, etc. It represents the nature of the LSP, and not the nature of PDH, etc. It represents the nature of the LSP, and not the nature of
the links that the LSP traverses. This is used hop-by-hop by each the links that the LSP traverses. This is used hop-by-hop by each
node. node.
E. Mannie et. al. Internet-Draft September 2002 27
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
A link may support a set of encoding formats, where support means A link may support a set of encoding formats, where support means
that a link is able to carry and switch a signal of one or more of that a link is able to carry and switch a signal of one or more of
these encoding formats. The Switching Type indicates then the type these encoding formats. The Switching Type indicates then the type
of switching that should be performed on a particular link for that of switching that should be performed on a particular link for that
LSP. This information is needed for links that advertise more than LSP. This information is needed for links that advertise more than
one type of switching capability. one type of switching capability.
Nodes must verify that the type indicated in the Switching Type is Nodes must verify that the type indicated in the Switching Type is
supported on the corresponding incoming interface; otherwise the node supported on the corresponding incoming interface; otherwise the
must generate a notification message with a "Routing node must generate a notification message with a "Routing
problem/Switching Type" indication. problem/Switching Type" indication.
The LSP payload type (G-PID) identifies the payload carried by the The LSP payload type (G-PID) identifies the payload carried by the
LSP, i.e. an identifier of the client layer of that LSP. For some LSP, i.e. an identifier of the client layer of that LSP. For some
technologies it also indicates the mapping used by the client layer, technologies it also indicates the mapping used by the client layer,
e.g. byte synchronous mapping of E1. This must be interpreted e.g. byte synchronous mapping of E1. This must be interpreted
according to the LSP encoding type of the LSP and is used by the according to the LSP encoding type of the LSP and is used by the
nodes at the endpoints of the LSP to know to which client layer a nodes at the endpoints of the LSP to know to which client layer a
request is destined, and in some cases by the penultimate hop. request is destined, and in some cases by the penultimate hop.
Other technology specific parameters are not transported in the Other technology specific parameters are not transported in the
Generalized Label Request but in technology specific traffic Generalized Label Request but in technology specific traffic
parameters as explained hereafter. Currently, two set of traffic parameters as explained hereafter. Currently, two set of traffic
parameters are defined, one for SONET/SDH and one for G.709. parameters are defined, one for SONET/SDH and one for G.709.
Note that it is expected than specific traffic parameters will be Note that it is expected than specific traffic parameters will be
defined in the future for photonic (all optical) switching. defined in the future for photonic (all optical) switching.
E. Mannie et. al. Internet-Draft February 2003 30
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
9.3. SONET/SDH Traffic Parameters 9.3. SONET/SDH Traffic Parameters
The GMPLS SDH/SONET traffic parameters [SONETSDH-GMPLS] specify a The GMPLS SDH/SONET traffic parameters [SONETSDH-GMPLS] specify a
powerful set of capabilities for SONET (ANSI T1.105) and SDH (ITU-T powerful set of capabilities for SONET (ANSI T1.105) and SDH (ITU-T
G.707). Optional non-standard capabilities are also available in G.707). Optional non-standard capabilities are also available in
[SONETSDH-EXT-GMPLS]. [SONETSDH-EXT-GMPLS].
The first traffic parameter specifies the type of the elementary The first traffic parameter specifies the type of the elementary
SONET/SDH signal that comprises the requested LSP, e.g. VC-11, VT6, SONET/SDH signal that comprises the requested LSP, e.g. VC-11, VT6,
VC-4, STS-3c, etc. Several transforms can then be applied VC-4, STS-3c, etc. Several transforms can then be applied
skipping to change at line 1568 skipping to change at line 1685
- First, contiguous concatenation can be optionally applied on the - First, contiguous concatenation can be optionally applied on the
Elementary Signal, resulting in a contiguously concatenated Elementary Signal, resulting in a contiguously concatenated
signal. signal.
- Second, virtual concatenation can be optionally applied either - Second, virtual concatenation can be optionally applied either
directly on the elementary Signal, or on the contiguously directly on the elementary Signal, or on the contiguously
concatenated signal obtained from the previous phase. concatenated signal obtained from the previous phase.
- Third, some transparency can be optionally specified when - Third, some transparency can be optionally specified when
requesting a frame as signal rather than a container. Several requesting a frame as signal rather than a container. Several
transparency packages are defined. transparency packages are defined.
E. Mannie et. al. Internet-Draft September 2002 28
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
- Fourth, a multiplication can be optionally applied either directly - Fourth, a multiplication can be optionally applied either directly
on the elementary Signal, or on the contiguously concatenated on the elementary Signal, or on the contiguously concatenated
signal obtained from the first phase, or on the virtually signal obtained from the first phase, or on the virtually
concatenated signal obtained from the second phase, or on these concatenated signal obtained from the second phase, or on these
signals combined with some transparency. signals combined with some transparency.
For RSVP-TE, the SONET/SDH traffic parameters are carried in a new For RSVP-TE, the SONET/SDH traffic parameters are carried in a new
SENDER_TSPEC and FLOWSPEC. The same format is used for both. There SENDER_TSPEC and FLOWSPEC. The same format is used for both. There
is no Adspec associated with the SENDER_TSPEC, either it is omitted is no Adspec associated with the SENDER_TSPEC, either it is omitted
or a default value is used. The content of the FLOWSPEC object or a default value is used. The content of the FLOWSPEC object
skipping to change at line 1600 skipping to change at line 1713
Note that a general discussion on SDH/SONET and GMPLS can be found Note that a general discussion on SDH/SONET and GMPLS can be found
in [SDH/SONET-GMPLS-FRAMEWORK]. in [SDH/SONET-GMPLS-FRAMEWORK].
9.4. G.709 Traffic Parameters 9.4. G.709 Traffic Parameters
Simply said, an ITU-T G.709 based network is decomposed in two major Simply said, an ITU-T G.709 based network is decomposed in two major
layers: an optical layer (i.e. made of wavelengths) and a digital layers: an optical layer (i.e. made of wavelengths) and a digital
layer. These two layers are divided into sub-layers and switching layer. These two layers are divided into sub-layers and switching
occurs at two specific sub-layers: at the OCh (Optical Channel) occurs at two specific sub-layers: at the OCh (Optical Channel)
E. Mannie et. al. Internet-Draft February 2003 31
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
optical layer and at the ODU (Optical channel Data Unit) electrical optical layer and at the ODU (Optical channel Data Unit) electrical
layer. The ODUk notation is used to denotes ODUs at different layer. The ODUk notation is used to denotes ODUs at different
bandwidths. bandwidths.
The GMPLS G.709 traffic parameters [G709-GMPLS] specify a powerful The GMPLS G.709 traffic parameters [G709-GMPLS] specify a powerful
set of capabilities for ITU-T G.709 networks. set of capabilities for ITU-T G.709 networks.
The first traffic parameter specifies the type of the elementary The first traffic parameter specifies the type of the elementary
G.709 signal that comprises the requested LSP, e.g. ODU1, OCh at 40 G.709 signal that comprises the requested LSP, e.g. ODU1, OCh at 40
Gbps, etc. Several transforms can then be applied successively on Gbps, etc. Several transforms can then be applied successively on
skipping to change at line 1625 skipping to change at line 1742
be applied strictly in the following order: be applied strictly in the following order:
- First, virtual concatenation can be optionally applied directly on - First, virtual concatenation can be optionally applied directly on
the elementary Signal, the elementary Signal,
- Second, a multiplication can be optionally applied, either - Second, a multiplication can be optionally applied, either
directly on the elementary Signal, or on the virtually directly on the elementary Signal, or on the virtually
concatenated signal obtained from the first phase. concatenated signal obtained from the first phase.
Additional ODUk Multiplexing traffic parameters allow indicating an Additional ODUk Multiplexing traffic parameters allow indicating an
ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request. ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request.
E. Mannie et. al. Internet-Draft September 2002 29
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
G.709 supports the following multiplexing capabilities: ODUj into G.709 supports the following multiplexing capabilities: ODUj into
ODUk (k > j); and ODU1 with ODU2 multiplexing into ODU3. ODUk (k > j); and ODU1 with ODU2 multiplexing into ODU3.
For RSVP-TE, the SONET/SDH traffic parameters are carried in a new For RSVP-TE, the SONET/SDH traffic parameters are carried in a new
SENDER-TSPEC and FLOWSPEC. The same format is used for both. There SENDER-TSPEC and FLOWSPEC. The same format is used for both. There
is no Adspec associated with the SENDER_TSPEC, either it is omitted is no Adspec associated with the SENDER_TSPEC, either it is omitted
or a default value is used. The content of the FLOWSPEC object or a default value is used. The content of the FLOWSPEC object
received in a Resv message should be identical to the content of the received in a Resv message should be identical to the content of the
SENDER_TSPEC of the corresponding Path message. SENDER_TSPEC of the corresponding Path message.
skipping to change at line 1657 skipping to change at line 1770
(the unit is bytes per second). Values are carried in a per protocol (the unit is bytes per second). Values are carried in a per protocol
specific manner. For non-packet LSPs, it is useful to define specific manner. For non-packet LSPs, it is useful to define
discrete values to identify the bandwidth of the LSP. discrete values to identify the bandwidth of the LSP.
It should be noted that this bandwidth encoding do not apply to It should be noted that this bandwidth encoding do not apply to
SONET/SDH and G.709, for which the traffic parameters fully define SONET/SDH and G.709, for which the traffic parameters fully define
the requested SONET/SDH or G.709 signal. the requested SONET/SDH or G.709 signal.
The bandwidth is coded in the Peak Data Rate field of Int-Serv The bandwidth is coded in the Peak Data Rate field of Int-Serv
objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects; and in objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects; and in
E. Mannie et. al. Internet-Draft February 2003 32
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
the Peak and Committed Data Rate fields of the CR-LDP Traffic the Peak and Committed Data Rate fields of the CR-LDP Traffic
Parameters TLV. Parameters TLV.
9.6. Generalized Label 9.6. Generalized Label
The Generalized Label extends the traditional MPLS label by allowing The Generalized Label extends the traditional MPLS label by allowing
the representation of not only labels that travel in-band with the representation of not only labels that travel in-band with
associated data packets, but also (virtual) labels that identify associated data packets, but also (virtual) labels that identify
time-slots, wavelengths, or space division multiplexed positions. time-slots, wavelengths, or space division multiplexed positions.
skipping to change at line 1682 skipping to change at line 1799
label can be as simple as an integer value such as a wavelength label can be as simple as an integer value such as a wavelength
label or can be more elaborated such as an SDH/SONET or a G.709 label or can be more elaborated such as an SDH/SONET or a G.709
label. label.
SDH and SONET define each a multiplexing structure. These SDH and SONET define each a multiplexing structure. These
multiplexing structures will be used as naming trees to create multiplexing structures will be used as naming trees to create
unique labels. Such a label will identify the exact position (times- unique labels. Such a label will identify the exact position (times-
lot(s)) of a signal in a multiplexing structure. Since the SONET lot(s)) of a signal in a multiplexing structure. Since the SONET
multiplexing structure may be seen as a subset of the SDH multiplexing structure may be seen as a subset of the SDH
multiplexing structure, the same format of label is used for SDH and multiplexing structure, the same format of label is used for SDH and
E. Mannie et. al. Internet-Draft September 2002 30
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
SONET. A similar concept is applied to build a label at the G.709 SONET. A similar concept is applied to build a label at the G.709
ODU layer. ODU layer.
Since the nodes sending and receiving the Generalized Label know Since the nodes sending and receiving the Generalized Label know
what kinds of link they are using, the Generalized Label does not what kinds of link they are using, the Generalized Label does not
identify its type, instead the nodes are expected to know from the identify its type, instead the nodes are expected to know from the
context what type of label to expect. context what type of label to expect.
A Generalized Label only carries a single level of label, i.e. it is A Generalized Label only carries a single level of label, i.e. it is
non-hierarchical. When multiple levels of labels (LSPs within LSPs) non-hierarchical. When multiple levels of labels (LSPs within LSPs)
skipping to change at line 1714 skipping to change at line 1827
multiple wavelengths as a unit. This may reduce the distortion on multiple wavelengths as a unit. This may reduce the distortion on
the individual wavelengths and may allow tighter separation of the the individual wavelengths and may allow tighter separation of the
individual wavelengths. A Waveband label is defined to support this individual wavelengths. A Waveband label is defined to support this
special case. special case.
Waveband switching naturally introduces another level of label Waveband switching naturally introduces another level of label
hierarchy and as such the waveband is treated the same way all other hierarchy and as such the waveband is treated the same way all other
upper layer labels are treated. As far as the MPLS protocols are upper layer labels are treated. As far as the MPLS protocols are
concerned there is little difference between a waveband label and a concerned there is little difference between a waveband label and a
wavelength label except that semantically the waveband can be wavelength label except that semantically the waveband can be
E. Mannie et. al. Internet-Draft February 2003 33
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
subdivided into wavelengths whereas the wavelength can only be subdivided into wavelengths whereas the wavelength can only be
subdivided into time or statistically multiplexed labels. subdivided into time or statistically multiplexed labels.
In the context of waveband switching, the generalized label used to In the context of waveband switching, the generalized label used to
indicate a waveband contains three fields, a waveband ID, a Start indicate a waveband contains three fields, a waveband ID, a Start
Label and an End Label. The Start and End Labels are channel Label and an End Label. The Start and End Labels are channel
identifiers from the sender perspective that identify respectively, identifiers from the sender perspective that identify respectively,
the lowest value wavelength and the highest value wavelength making the lowest value wavelength and the highest value wavelength making
up the waveband. up the waveband.
skipping to change at line 1740 skipping to change at line 1857
optical equipment where there may be a lengthy (in electrical terms) optical equipment where there may be a lengthy (in electrical terms)
delay in configuring the switching fabric. For example micro mirrors delay in configuring the switching fabric. For example micro mirrors
may have to be elevated or moved, and this physical motion and may have to be elevated or moved, and this physical motion and
subsequent damping takes time. If the labels and hence switching subsequent damping takes time. If the labels and hence switching
fabric are configured in the reverse direction (the norm) the fabric are configured in the reverse direction (the norm) the
MAPPING/Resv message may need to be delayed by 10's of milliseconds MAPPING/Resv message may need to be delayed by 10's of milliseconds
per hop in order to establish a usable forwarding path. It can be per hop in order to establish a usable forwarding path. It can be
important for restoration purposes where alternate LSPs may need to important for restoration purposes where alternate LSPs may need to
be rapidly established as a result of network failures. be rapidly established as a result of network failures.
E. Mannie et. al. Internet-Draft September 2002 31
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
9.9. Label Restriction by the Upstream 9.9. Label Restriction by the Upstream
An upstream node can optionally restrict (limit) the choice of label An upstream node can optionally restrict (limit) the choice of label
of a downstream node to a set of acceptable labels. Giving lists of a downstream node to a set of acceptable labels. Giving lists
and/or ranges of inclusive (acceptable) or exclusive (unacceptable) and/or ranges of inclusive (acceptable) or exclusive (unacceptable)
labels in a Label Set provides this restriction. If not applied, all labels in a Label Set provides this restriction. If not applied, all
labels from the valid label range may be used. There are at least labels from the valid label range may be used. There are at least
four cases where a label restriction is useful in the "optical" four cases where a label restriction is useful in the "optical"
domain. domain.
skipping to change at line 1771 skipping to change at line 1885
3. The third case is where it is desirable to limit the amount of 3. The third case is where it is desirable to limit the amount of
wavelength conversion being performed to reduce the distortion on wavelength conversion being performed to reduce the distortion on
the optical signals. the optical signals.
4. The last case is where two ends of a link support different sets 4. The last case is where two ends of a link support different sets
of wavelengths. of wavelengths.
The receiver of a Label Set must restrict its choice of labels to The receiver of a Label Set must restrict its choice of labels to
one that is in the Label Set. A Label Set may be present across one that is in the Label Set. A Label Set may be present across
multiple hops. In this case each node generates it's own outgoing multiple hops. In this case each node generates it's own outgoing
E. Mannie et. al. Internet-Draft February 2003 34
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Label Set, possibly based on the incoming Label Set and the node's Label Set, possibly based on the incoming Label Set and the node's
hardware capabilities. This case is expected to be the norm for hardware capabilities. This case is expected to be the norm for
nodes with conversion incapable interfaces. nodes with conversion incapable interfaces.
9.10. Bi-directional LSP 9.10. Bi-directional LSP
GMPLS allows establishment of bi-directional symmetric LSPs (not of GMPLS allows establishment of bi-directional symmetric LSPs (not of
asymmetric LSPs). A symmetric bi-directional LSP has the same asymmetric LSPs). A symmetric bi-directional LSP has the same
traffic engineering requirements including fate sharing, protection traffic engineering requirements including fate sharing, protection
and restoration, LSRs, and resource requirements (e.g. latency and and restoration, LSRs, and resource requirements (e.g. latency and
skipping to change at line 1796 skipping to change at line 1914
LSP. For a bi-directional LSPs, there is only one initiator and one LSP. For a bi-directional LSPs, there is only one initiator and one
terminator. terminator.
Normally to establish a bi-directional LSP when using [RSVP-TE] or Normally to establish a bi-directional LSP when using [RSVP-TE] or
[CR-LDP] two unidirectional paths must be independently established. [CR-LDP] two unidirectional paths must be independently established.
This approach has the following disadvantages: This approach has the following disadvantages:
1. The latency to establish the bi-directional LSP is equal to one 1. The latency to establish the bi-directional LSP is equal to one
round trip signaling time plus one initiator-terminator signaling round trip signaling time plus one initiator-terminator signaling
transit delay. This not only extends the setup latency for transit delay. This not only extends the setup latency for
E. Mannie et. al. Internet-Draft September 2002 32
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
successful LSP establishment, but it extends the worst-case latency successful LSP establishment, but it extends the worst-case latency
for discovering an unsuccessful LSP to as much as two times the for discovering an unsuccessful LSP to as much as two times the
initiator-terminator transit delay. These delays are particularly initiator-terminator transit delay. These delays are particularly
significant for LSPs that are established for restoration purposes. significant for LSPs that are established for restoration purposes.
2. The control overhead is twice that of a unidirectional LSP. This 2. The control overhead is twice that of a unidirectional LSP. This
is because separate control messages (e.g. Path and Resv) must be is because separate control messages (e.g. Path and Resv) must be
generated for both segments of the bi-directional LSP. generated for both segments of the bi-directional LSP.
3. Because the resources are established in separate segments, route 3. Because the resources are established in separate segments, route
skipping to change at line 1828 skipping to change at line 1942
the control information in-band with the data. the control information in-band with the data.
5. Bi-directional optical LSPs (or lightpaths) are seen as a 5. Bi-directional optical LSPs (or lightpaths) are seen as a
requirement for many optical networking service providers. requirement for many optical networking service providers.
With bi-directional LSPs both the downstream and upstream data With bi-directional LSPs both the downstream and upstream data
paths, i.e. from initiator to terminator and terminator to paths, i.e. from initiator to terminator and terminator to
initiator, are established using a single set of signaling messages. initiator, are established using a single set of signaling messages.
This reduces the setup latency to essentially one initiator- This reduces the setup latency to essentially one initiator-
terminator round trip time plus processing time, and limits the terminator round trip time plus processing time, and limits the
E. Mannie et. al. Internet-Draft February 2003 35
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
control overhead to the same number of messages as a unidirectional control overhead to the same number of messages as a unidirectional
LSP. LSP.
For bi-directional LSPs, two labels must be allocated. Bi- For bi-directional LSPs, two labels must be allocated. Bi-
directional LSP setup is indicated by the presence of an Upstream directional LSP setup is indicated by the presence of an Upstream
Label in the appropriate signaling message. Label in the appropriate signaling message.
9.11. Bi-directional LSP Contention Resolution 9.11. Bi-directional LSP Contention Resolution
Contention for labels may occur between two bi-directional LSP setup Contention for labels may occur between two bi-directional LSP setup
skipping to change at line 1851 skipping to change at line 1969
that contention, basically the node with the higher node ID will win that contention, basically the node with the higher node ID will win
the contention. To reduce the probability of contention, some the contention. To reduce the probability of contention, some
mechanisms are also suggested. mechanisms are also suggested.
9.12. Rapid Notification of Failure 9.12. Rapid Notification of Failure
GMPLS defines several signaling extensions that enable expedited GMPLS defines several signaling extensions that enable expedited
notification of failures and other events to nodes responsible for notification of failures and other events to nodes responsible for
restoring failed LSPs, and error handling. restoring failed LSPs, and error handling.
E. Mannie et. al. Internet-Draft September 2002 33
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
1. Acceptable Label Set for notification on Label Error: 1. Acceptable Label Set for notification on Label Error:
There are cases in traditional MPLS and in GMPLS that result in an There are cases in traditional MPLS and in GMPLS that result in an
error message containing an "Unacceptable label value" indication. error message containing an "Unacceptable label value" indication.
When these cases occur, it can useful for the node generating the When these cases occur, it can useful for the node generating the
error message to indicate which labels would be acceptable. To cover error message to indicate which labels would be acceptable. To cover
this case, GMPLS introduces the ability to convey such information this case, GMPLS introduces the ability to convey such information
via the "Acceptable Label Set". An Acceptable Label Set is carried via the "Acceptable Label Set". An Acceptable Label Set is carried
in appropriate protocol specific error messages. The format of an in appropriate protocol specific error messages. The format of an
Acceptable Label Set is identical to a Label Set. Acceptable Label Set is identical to a Label Set.
skipping to change at line 1885 skipping to change at line 2000
The Notify message differs from the currently defined error messages The Notify message differs from the currently defined error messages
in that it can be "targeted" to a node other than the immediate in that it can be "targeted" to a node other than the immediate
upstream or downstream neighbor and that it is a generalized upstream or downstream neighbor and that it is a generalized
notification mechanism. The Notify message does not replace existing notification mechanism. The Notify message does not replace existing
error messages. The Notify message may be sent either (a) normally, error messages. The Notify message may be sent either (a) normally,
where non-target nodes just forward the Notify message to the target where non-target nodes just forward the Notify message to the target
node, similar to ResvConf processing in [RSVP]; or (b) encapsulated node, similar to ResvConf processing in [RSVP]; or (b) encapsulated
in a new IP header whose destination is equal to the target IP in a new IP header whose destination is equal to the target IP
address. address.
E. Mannie et. al. Internet-Draft February 2003 36
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
3. Faster removal of intermediate states: 3. Faster removal of intermediate states:
A specific RSVP optimization allowing in some cases the faster A specific RSVP optimization allowing in some cases the faster
removal of intermediate states. This extension is used to deal with removal of intermediate states. This extension is used to deal with
specific RSVP mechanisms. specific RSVP mechanisms.
9.13. Link Protection 9.13. Link Protection
Protection information is carried in the new optional Protection Protection information is carried in the new optional Protection
Information Object/TLV. It currently indicates the desired link Information Object/TLV. It currently indicates the desired link
skipping to change at line 1909 skipping to change at line 2027
routing protocols. Path computation algorithms may take this routing protocols. Path computation algorithms may take this
information into account when computing paths for setting up LSPs. information into account when computing paths for setting up LSPs.
Protection information also indicates if the LSP is a primary or Protection information also indicates if the LSP is a primary or
secondary LSP. A secondary LSP is a backup to a primary LSP. The secondary LSP. A secondary LSP is a backup to a primary LSP. The
resources of a secondary LSP are normally not used until the primary resources of a secondary LSP are normally not used until the primary
LSP fails, but they may be used by other LSPs until the primary LSP LSP fails, but they may be used by other LSPs until the primary LSP
fails over the secondary LSP. At that point, any LSP that is using fails over the secondary LSP. At that point, any LSP that is using
the resources for the secondary LSP must be preempted. the resources for the secondary LSP must be preempted.
E. Mannie et. al. Internet-Draft September 2002 34
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
Six link protection types are currently defined as individual flags Six link protection types are currently defined as individual flags
and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared, and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared,
unprotected, extra traffic. See [GMPLS-SIG] section 7.1 for a unprotected, extra traffic. See [GMPLS-SIG] section 7.1 for a
precise definition of each. precise definition of each.
9.14. Explicit Routing and Explicit Label Control 9.14. Explicit Routing and Explicit Label Control
By using an explicit route the path taken by an LSP can be By using an explicit route the path taken by an LSP can be
controlled more or less precisely. Typically, the node at the head- controlled more or less precisely. Typically, the node at the head-
end of an LSP finds an explicit route and builds an Explicit Route end of an LSP finds an explicit route and builds an Explicit Route
skipping to change at line 1942 skipping to change at line 2057
abstract node can be an IPv4 address prefix, an IPv6 address prefix, abstract node can be an IPv4 address prefix, an IPv6 address prefix,
or an AS number. This capability allows the generator of the or an AS number. This capability allows the generator of the
explicit route to have incomplete information about the details of explicit route to have incomplete information about the details of
the path. In the simplest case, an abstract node can be a full IP the path. In the simplest case, an abstract node can be a full IP
address (32 bits) that identifies a specific node (called a simple address (32 bits) that identifies a specific node (called a simple
abstract node). abstract node).
MPLS-TE allows strict and loose abstract nodes. The path between a MPLS-TE allows strict and loose abstract nodes. The path between a
strict node and its preceding node must include only network nodes strict node and its preceding node must include only network nodes
from the strict node and its preceding abstract node. The path from the strict node and its preceding abstract node. The path
E. Mannie et. al. Internet-Draft February 2003 37
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
between a loose node and its preceding abstract node may include between a loose node and its preceding abstract node may include
other network nodes that are not part of the loose node or its other network nodes that are not part of the loose node or its
preceding abstract node. preceding abstract node.
This explicit route was extended to include interface numbers as This explicit route was extended to include interface numbers as
abstract nodes to support unnumbered interfaces; and further abstract nodes to support unnumbered interfaces; and further
extended by GMPLS to include labels as abstract nodes. Having labels extended by GMPLS to include labels as abstract nodes. Having labels
in an explicit route is an important feature that allows controlling in an explicit route is an important feature that allows controlling
the placement of an LSP with a very fine granularity. This is more the placement of an LSP with a very fine granularity. This is more
likely to be used for TDM, LSC and FSC links. likely to be used for TDM, LSC and FSC links.
skipping to change at line 1964 skipping to change at line 2083
allows terminating an LSP on a particular outgoing port of an egress allows terminating an LSP on a particular outgoing port of an egress
node. Indeed, a label sub-object/TLV must follow a sub-object/TLV node. Indeed, a label sub-object/TLV must follow a sub-object/TLV
containing the IP address, or the interface identifier (in case of containing the IP address, or the interface identifier (in case of
unnumbered interface), associated with the link on which it is to be unnumbered interface), associated with the link on which it is to be
used. used.
This can also be used when it is desirable to "splice" two LSPs This can also be used when it is desirable to "splice" two LSPs
together, i.e. where the tail of the first LSP would be "spliced" together, i.e. where the tail of the first LSP would be "spliced"
into the head of the second LSP. into the head of the second LSP.
E. Mannie et. al. Internet-Draft September 2002 35
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
Another use is when an optimization algorithm is used for an Another use is when an optimization algorithm is used for an
SDH/SONET network. This algorithm can provide very detailed explicit SDH/SONET network. This algorithm can provide very detailed explicit
routes, including the label (time-slot) to use on a link, in order routes, including the label (time-slot) to use on a link, in order
to minimize the fragmentation of the SDH/SONET multiplex on the to minimize the fragmentation of the SDH/SONET multiplex on the
corresponding interface. corresponding interface.
9.15. Route recording 9.15. Route recording
In order to improve the reliability and the manageability of the LSP In order to improve the reliability and the manageability of the LSP
being established, the concept of the route recording was introduced being established, the concept of the route recording was introduced
skipping to change at line 1999 skipping to change at line 2115
- Third, a recorded route can be used as input for an explicit - Third, a recorded route can be used as input for an explicit
route. This is useful if a source node receives the recorded route route. This is useful if a source node receives the recorded route
from a destination node and applies it as an explicit route in order from a destination node and applies it as an explicit route in order
to "pin down the path". to "pin down the path".
Within the GMPLS architecture only the second and third functions Within the GMPLS architecture only the second and third functions
are mainly applicable for TDM, LSC and FSC layers. are mainly applicable for TDM, LSC and FSC layers.
9.16. LSP modification and LSP re-routing 9.16. LSP modification and LSP re-routing
E. Mannie et. al. Internet-Draft February 2003 38
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
LSP modification and re-routing are two features already available LSP modification and re-routing are two features already available
in MPLS-TE. GMPLS does not add anything new. Elegant re-routing is in MPLS-TE. GMPLS does not add anything new. Elegant re-routing is
possible with the concept of "make-before-break" whereby an old path possible with the concept of "make-before-break" whereby an old path
is still used while a new path is set up by avoiding double is still used while a new path is set up by avoiding double
reservation of resources. Then, the node performing the re-routing reservation of resources. Then, the node performing the re-routing
can swap on the new path and close the old path. This feature is can swap on the new path and close the old path. This feature is
supported with RSVP-TE (using shared explicit filters) and CR-LDP supported with RSVP-TE (using shared explicit filters) and CR-LDP
(using the action indicator flag). (using the action indicator flag).
LSP modification consists in changing some LSP parameters, but LSP modification consists in changing some LSP parameters, but
normally without changing the route. It is supported using the same normally without changing the route. It is supported using the same
mechanism as re-routing. However, the semantic of LSP modification mechanism as re-routing. However, the semantic of LSP modification
will differ from one technology to the other. For instance, further will differ from one technology to the other. For instance, further
studies are required to understand the impact of dynamically studies are required to understand the impact of dynamically
changing some SDH/SONET circuit characteristics such as the changing some SDH/SONET circuit characteristics such as the
bandwidth, the protection type, the transparency, the concatenation, bandwidth, the protection type, the transparency, the concatenation,
etc. etc.
E. Mannie et. al. Internet-Draft September 2002 36
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
9.17. LSP administrative status handling 9.17. LSP administrative status handling
GMPLS provides the optional capability to indicate the GMPLS provides the optional capability to indicate the
administrative status of an LSP by using a new Admin Status administrative status of an LSP by using a new Admin Status
object/TLV. Administrative Status Information is currently used in object/TLV. Administrative Status Information is currently used in
two ways. two ways.
In the first usage, Admin Status the object/TLV is carried in a In the first usage, Admin Status the object/TLV is carried in a
Path/Label Request or Resv/Label Mapping message to indicate the Path/Label Request or Resv/Label Mapping message to indicate the
administrative state of an LSP. In this usage, Administrative Status administrative state of an LSP. In this usage, Administrative Status
skipping to change at line 2057 skipping to change at line 2173
The ingress LSR precedes an LSP deletion by inserting an appropriate The ingress LSR precedes an LSP deletion by inserting an appropriate
Admin Status Object/TLV in a Path/Label Request (with the Admin Status Object/TLV in a Path/Label Request (with the
modification action indicator flag set to modify) message. Transit modification action indicator flag set to modify) message. Transit
LSRs process the Admin Status Object/TLV and forward it. The egress LSRs process the Admin Status Object/TLV and forward it. The egress
LSR answers in a Resv/Label Mapping (with the modification action LSR answers in a Resv/Label Mapping (with the modification action
indicator flag set to modify) message with the Admin Status object. indicator flag set to modify) message with the Admin Status object.
Upon receiving this message and object, the ingress node sends a Upon receiving this message and object, the ingress node sends a
PathTear/Release message downstream to remove the LSP and normal PathTear/Release message downstream to remove the LSP and normal
RSVP/CR-LDP processing takes place. RSVP/CR-LDP processing takes place.
E. Mannie et. al. Internet-Draft February 2003 39
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
In the second usage, the Admin Status object/TLV is carried in a In the second usage, the Admin Status object/TLV is carried in a
Notification/Label Mapping (with the modification action indicator Notification/Label Mapping (with the modification action indicator
flag set to modify) message to request that the ingress node change flag set to modify) message to request that the ingress node change
the administrative state of an LSP. This allows intermediate and the administrative state of an LSP. This allows intermediate and
egress nodes to trigger the setting of administrative status. In egress nodes to trigger the setting of administrative status. In
particular this allows, intermediate or egress LSRs to request a particular this allows, intermediate or egress LSRs to request a
release of an LSP initiated by the ingress node. release of an LSP initiated by the ingress node.
9.18. Control channel separation 9.18. Control channel separation
In GMPLS, a control channel can be separated from the data channel. In GMPLS, a control channel can be separated from the data channel.
Indeed, the control channel can be implemented completely out-of- Indeed, the control channel can be implemented completely out-of-
band for various reasons, e.g. when the data channel cannot carry band for various reasons, e.g. when the data channel cannot carry
in-band control information. This issue was even originally in-band control information. This issue was even originally
introduced to MPLS in connection with link bundling. introduced to MPLS in connection with link bundling.
E. Mannie et. al. Internet-Draft September 2002 37
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
In traditional MPLS there is an implicit one-to-one association of a In traditional MPLS there is an implicit one-to-one association of a
control channel to a data channel. When such an association is control channel to a data channel. When such an association is
present, no additional or special information is required to present, no additional or special information is required to
associate a particular LSP setup transaction with a particular data associate a particular LSP setup transaction with a particular data
channel. channel.
Otherwise it is necessary to convey additional information in Otherwise it is necessary to convey additional information in
signaling to identify the particular data channel being controlled. signaling to identify the particular data channel being controlled.
GMPLS supports explicit data channel identification by providing GMPLS supports explicit data channel identification by providing
interface identification information. GMPLS allows the use of a interface identification information. GMPLS allows the use of a
skipping to change at line 2111 skipping to change at line 2227
message to indicate the downstream node's usage of the indicated message to indicate the downstream node's usage of the indicated
interface(s). interface(s).
The new object/TLV can contain a list of embedded TLVs, each The new object/TLV can contain a list of embedded TLVs, each
embedded TLV can be an IPv4 address, and IPv6 address, an interface embedded TLV can be an IPv4 address, and IPv6 address, an interface
index, a downstream component interface ID or an upstream component index, a downstream component interface ID or an upstream component
interface ID. In the last three cases, the embedded TLV contains interface ID. In the last three cases, the embedded TLV contains
itself an IP address plus an Interface ID, the IP address being used itself an IP address plus an Interface ID, the IP address being used
to identify the interface ID (it can be the router ID for instance). to identify the interface ID (it can be the router ID for instance).
E. Mannie et. al. Internet-Draft February 2003 40
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
There are cases where it is useful to indicate a specific interface There are cases where it is useful to indicate a specific interface
associated with an error. To support these cases the IF_ID associated with an error. To support these cases the IF_ID
ERROR_SPEC RSVP Objects are defined. ERROR_SPEC RSVP Objects are defined.
10. Forwarding Adjacencies (FA) 10. Forwarding Adjacencies (FA)
To improve scalability of MPLS TE (and thus GMPLS) it may be useful To improve scalability of MPLS TE (and thus GMPLS) it may be useful
to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate
nodes see the external LSP only, they don't have to maintain nodes see the external LSP only, they don't have to maintain
forwarding states for each internal LSP, less signaling messages forwarding states for each internal LSP, less signaling messages
need to be exchanged and the external LSP can be somehow protected need to be exchanged and the external LSP can be somehow protected
instead (or in addition) to the internal LSPs. This can considerably instead (or in addition) to the internal LSPs. This can considerably
increase the scalability of the signaling. increase the scalability of the signaling.
The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) The aggregation is accomplished by (a) an LSR creating a TE LSP, (b)
the LSR forming a forwarding adjacency out of that LSP (advertising the LSR forming a forwarding adjacency out of that LSP (advertising
this LSP as a Traffic Engineering (TE) link into ISIS/OSPF), (c) this LSP as a Traffic Engineering (TE) link into ISIS/OSPF), (c)
allowing other LSRs to use forwarding adjacencies for their path allowing other LSRs to use forwarding adjacencies for their path
computation, and (d) nesting of LSPs originated by other LSRs into computation, and (d) nesting of LSPs originated by other LSRs into
E. Mannie et. al. Internet-Draft September 2002 38
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
that LSP (e.g. by using the label stack construct in the case of that LSP (e.g. by using the label stack construct in the case of
IP). IP).
An LSR may (under its local configuration control) announce an LSP An LSR may (under its local configuration control) announce an LSP
as a TE link into ISIS/OSPF. When this link is advertised into the as a TE link into ISIS/OSPF. When this link is advertised into the
same instance of ISIS/OSPF as the one that determines the route same instance of ISIS/OSPF as the one that determines the route
taken by the LSP, we call such a link a "forwarding adjacency" (FA). taken by the LSP, we call such a link a "forwarding adjacency" (FA).
We refer to the LSP as the "forwarding adjacency LSP", or just FA- We refer to the LSP as the "forwarding adjacency LSP", or just FA-
LSP. Note that since the advertised entity is a link in ISIS/OSPF, LSP. Note that since the advertised entity is a link in ISIS/OSPF,
both the endpoint LSRs of the FA-LSP must belong to the same ISIS both the endpoint LSRs of the FA-LSP must belong to the same ISIS
skipping to change at line 2168 skipping to change at line 2283
An LSR, when performing path computation, uses not just conventional An LSR, when performing path computation, uses not just conventional
links, but FAs as well. Once a path is computed, the LSR uses RSVP- links, but FAs as well. Once a path is computed, the LSR uses RSVP-
TE/CR-LDP for establishing label binding along the path. FAs need TE/CR-LDP for establishing label binding along the path. FAs need
simple extensions to signaling and routing protocols. simple extensions to signaling and routing protocols.
10.1. Routing and Forwarding Adjacencies 10.1. Routing and Forwarding Adjacencies
Forwarding adjacencies may be represented as either unnumbered or Forwarding adjacencies may be represented as either unnumbered or
numbered links. A FA can also be a bundle of LSPs between two nodes. numbered links. A FA can also be a bundle of LSPs between two nodes.
E. Mannie et. al. Internet-Draft February 2003 41
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
FAs are advertised as GMPLS TE links such as defined in [HIERARCHY]. FAs are advertised as GMPLS TE links such as defined in [HIERARCHY].
GMPLS TE links are advertised in OSPF and ISIS such as defined in GMPLS TE links are advertised in OSPF and ISIS such as defined in
[OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications
enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link. enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link.
When a FA is created dynamically, its TE attributes are inherited When a FA is created dynamically, its TE attributes are inherited
from the FA-LSP that induced its creation. [HIERARCHY] specifies how from the FA-LSP that induced its creation. [HIERARCHY] specifies how
each TE parameter of the FA is inherited from the FA-LSP. Note that each TE parameter of the FA is inherited from the FA-LSP. Note that
the bandwidth of the FA must be at least as big as the FA-LSP that the bandwidth of the FA must be at least as big as the FA-LSP that
induced it, but may be bigger if only discrete bandwidths are induced it, but may be bigger if only discrete bandwidths are
available for the FA-LSP. In general, for dynamically provisioned available for the FA-LSP. In general, for dynamically provisioned
forwarding adjacencies, a policy-based mechanism may be needed to forwarding adjacencies, a policy-based mechanism may be needed to
associate attributes to forwarding adjacencies. associate attributes to forwarding adjacencies.
A FA advertisement could contain the information about the path A FA advertisement could contain the information about the path
taken by the FA-LSP associated with that FA. Other LSRs may use this taken by the FA-LSP associated with that FA. Other LSRs may use this
information for path computation. This information is carried in a information for path computation. This information is carried in a
new OSPF and IS-IS TLV called the Path TLV. new OSPF and IS-IS TLV called the Path TLV.
E. Mannie et. al. Internet-Draft September 2002 39
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
It is possible that the underlying path information might change It is possible that the underlying path information might change
over time, via configuration updates, or dynamic route over time, via configuration updates, or dynamic route
modifications, resulting in the change of that TLV. modifications, resulting in the change of that TLV.
If forwarding adjacencies are bundled (via link bundling), and if If forwarding adjacencies are bundled (via link bundling), and if
the resulting bundled link carries a Path TLV, the underlying path the resulting bundled link carries a Path TLV, the underlying path
followed by each of the FA-LSPs that form the component links must followed by each of the FA-LSPs that form the component links must
be the same. be the same.
It is expected that forwarding adjacencies will not be used for It is expected that forwarding adjacencies will not be used for
skipping to change at line 2225 skipping to change at line 2340
For the purpose of processing the explicit route in a Path/Request For the purpose of processing the explicit route in a Path/Request
message of an LSP that is to be tunneled over a forwarding message of an LSP that is to be tunneled over a forwarding
adjacency, an LSR at the head-end of the FA-LSP views the LSR at the adjacency, an LSR at the head-end of the FA-LSP views the LSR at the
tail of that FA-LSP as adjacent (one IP hop away). tail of that FA-LSP as adjacent (one IP hop away).
10.3. Cascading of Forwarding Adjacencies 10.3. Cascading of Forwarding Adjacencies
With an integrated model several layers are controlled using the With an integrated model several layers are controlled using the
same routing and signaling protocols. A network may then have links same routing and signaling protocols. A network may then have links
with different multiplexing/demultiplexing capabilities. For with different multiplexing/demultiplexing capabilities. For
E. Mannie et. al. Internet-Draft February 2003 42
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
example, a node may be able to multiplex/demultiplex individual example, a node may be able to multiplex/demultiplex individual
packets on a given link, and may be able to multiplex/demultiplex packets on a given link, and may be able to multiplex/demultiplex
channels within a SONET payload on other links. channels within a SONET payload on other links.
A new OSPF and IS-IS sub-TLV has been defined to advertise the A new OSPF and IS-IS sub-TLV has been defined to advertise the
multiplexing capability of each interface: PSC, L2SC, TDM, LSC or multiplexing capability of each interface: PSC, L2SC, TDM, LSC or
FSC. This sub-TLV is named the Link Multiplex Capability sub-TLV and FSC. This sub-TLV is named the Link Multiplex Capability sub-TLV and
complements the sub-TLVs defined in [OSPF-TE-GMPLS] and [ISIS-TE- complements the sub-TLVs defined in [OSPF-TE-GMPLS] and [ISIS-TE-
GMPLS]. The information carried in this sub-TLV is used to construct GMPLS]. The information carried in this sub-TLV is used to construct
LSP regions, and determine regionÆs boundaries. LSP regions, and determine regionÆs boundaries.
Path computation may take into account region boundaries when Path computation may take into account region boundaries when
computing a path for an LSP. For example, path computation may computing a path for an LSP. For example, path computation may
restrict the path taken by an LSP to only the links whose restrict the path taken by an LSP to only the links whose
multiplexing/demultiplexing capability is PSC. When an LSP need to multiplexing/demultiplexing capability is PSC. When an LSP need to
cross a region boundary, it can trigger the establishment of an FA cross a region boundary, it can trigger the establishment of an FA
at the underlying layer (i.e. the L2SC layer). This can trigger a at the underlying layer (i.e. the L2SC layer). This can trigger a
cascading of FAs between layers with the following obvious order: cascading of FAs between layers with the following obvious order:
L2SC, then TDM, then LSC, and then finally FSC. L2SC, then TDM, then LSC, and then finally FSC.
E. Mannie et. al. Internet-Draft September 2002 40
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
11. Routing and Signaling Adjacencies 11. Routing and Signaling Adjacencies
By definition, two nodes have a routing (ISIS/OSPF) adjacency if By definition, two nodes have a routing (ISIS/OSPF) adjacency if
they are neighbors in the ISIS/OSPF sense. they are neighbors in the ISIS/OSPF sense.
By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency
if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are
RSVP-TE neighbors if they directly exchange RSVP-TE messages RSVP-TE neighbors if they directly exchange RSVP-TE messages
(Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of
[HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE [HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE
skipping to change at line 2282 skipping to change at line 2398
two nodes, there must be an IP path between them. This IP path can two nodes, there must be an IP path between them. This IP path can
be, for example, a TE Link with an interface switching capability of be, for example, a TE Link with an interface switching capability of
PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a
(bi-directional) LSP that with an interface switching capability of (bi-directional) LSP that with an interface switching capability of
PSC). PSC).
A TE link may not be capable of being used directly for maintaining A TE link may not be capable of being used directly for maintaining
routing and/or signaling adjacencies. This is because GMPLS routing routing and/or signaling adjacencies. This is because GMPLS routing
and signaling adjacencies requires exchanging data on a per (IP/ISO) and signaling adjacencies requires exchanging data on a per (IP/ISO)
packet basis, and a TE link (e.g. a link between OXCs) may not be packet basis, and a TE link (e.g. a link between OXCs) may not be
E. Mannie et. al. Internet-Draft February 2003 43
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
capable of exchanging data on a per packet basis. In this case the capable of exchanging data on a per packet basis. In this case the
routing and signaling adjacencies are maintained via a set of one or routing and signaling adjacencies are maintained via a set of one or
more control channels (see [LMP]). more control channels (see [LMP]).
Two nodes may have a TE link between them even if they don't have a Two nodes may have a TE link between them even if they don't have a
routing adjacency. Naturally, each node must run OSPF/ISIS with routing adjacency. Naturally, each node must run OSPF/ISIS with
GMPLS extensions in order for that TE link to be advertised. More GMPLS extensions in order for that TE link to be advertised. More
precisely, the node needs to run GMPLS extensions for TE Links with precisely, the node needs to run GMPLS extensions for TE Links with
an interface switching capability (see [GMPLS-ROUTING]) other than an interface switching capability (see [GMPLS-ROUTING]) other than
PSC, and it needs to run either GMPLS or MPLS extensions for TE PSC, and it needs to run either GMPLS or MPLS extensions for TE
links with an interface switching capability of PSC. links with an interface switching capability of PSC.
The mechanisms for Control Channel Separation [GMPLS-SIG] should be The mechanisms for Control Channel Separation [GMPLS-SIG] should be
used (even if the IP path between two nodes is a TE link). I.e., used (even if the IP path between two nodes is a TE link). I.e.,
RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object
to specify a particular TE link when establishing an LSP. to specify a particular TE link when establishing an LSP.
E. Mannie et. al. Internet-Draft September 2002 41
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
The IP path could consist of multiple IP hops. In this case, the The IP path could consist of multiple IP hops. In this case, the
mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used
(in addition to Control Channel Separation). (in addition to Control Channel Separation).
12. Control Plane Fault Handling 12. Control Plane Fault Handling
There are two major types of faults that can impact a control plane. There are two major types of faults that can impact a control plane.
The first, referred to as control channel fault, relates to the case The first, referred to as control channel fault, relates to the case
where control communication is lost between two neighboring nodes. where control communication is lost between two neighboring nodes.
If the control channel is embedded with the data channel, data If the control channel is embedded with the data channel, data
skipping to change at line 2340 skipping to change at line 2457
any state changes that were instantiated during the failure are any state changes that were instantiated during the failure are
synchronized between the nodes. synchronized between the nodes.
For a nodal fault, a node's control plane restarts and losses most For a nodal fault, a node's control plane restarts and losses most
of it's state information. In this case, both upstream and of it's state information. In this case, both upstream and
downstream nodes must synchronize their state information with the downstream nodes must synchronize their state information with the
restarted node. In order for any resynchronization to occur the node restarted node. In order for any resynchronization to occur the node
undergoing the restart will need to preserve some information, such undergoing the restart will need to preserve some information, such
as it's mappings of incoming to outgoing labels. as it's mappings of incoming to outgoing labels.
E. Mannie et. al. Internet-Draft February 2003 44
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
These issues are addressed in protocol specific fashions, see [RSVP- These issues are addressed in protocol specific fashions, see [RSVP-
TE-GMPLS] and [CR-LDP-GMPLS]. Note that these cases only apply when TE-GMPLS] and [CR-LDP-GMPLS]. Note that these cases only apply when
there are mechanisms to detect data channel failures independent of there are mechanisms to detect data channel failures independent of
control channel failures. control channel failures.
The LDP Fault tolerant draft [LDP-FT] specifies the procedures to The LDP Fault tolerant draft [LDP-FT] specifies the procedures to
recover from a control channel failure. [RSVP-TE-GMPLS] specifies recover from a control channel failure. [RSVP-TE-GMPLS] specifies
how to recover from both a control channel failure and a node how to recover from both a control channel failure and a node
failure. failure.
E. Mannie et. al. Internet-Draft September 2002 42
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
13. LSP Protection and Restoration 13. LSP Protection and Restoration
This section discusses Protection and Restoration (P&R) issues for This section discusses Protection and Restoration (P&R) issues for
GMPLS LSPs. It is driven by the requirements outlined in [TEWG- GMPLS LSPs. It is driven by the requirements outlined in [TEWG-
RESTORE] and some of the principles outlined in [MPLS-RECOVERY]. It RESTORE] and some of the principles outlined in [MPLS-RECOVERY]. It
will be enhanced, as more GMPLS P&R mechanisms are defined. The will be enhanced, as more GMPLS P&R mechanisms are defined. The
scope of this section is clarified hereafter: scope of this section is clarified hereafter:
- This section is only applicable when a fault impacting LSP(s) - This section is only applicable when a fault impacting LSP(s)
happens in the data/transport plane. Section 11 deals with control happens in the data/transport plane. Section 11 deals with control
skipping to change at line 2396 skipping to change at line 2513
- TDM, LSC and FSC devices are more generally committing recovery - TDM, LSC and FSC devices are more generally committing recovery
resources in a non best effort way. Recovery resources are either resources in a non best effort way. Recovery resources are either
allocated and used, or at least logically reserved (used or not by allocated and used, or at least logically reserved (used or not by
preemptable extra traffic but unavailable anyway for regular preemptable extra traffic but unavailable anyway for regular
working traffic). working traffic).
- Shared P&R mechanisms are valuable to operators in order to - Shared P&R mechanisms are valuable to operators in order to
maximize their network utilization. maximize their network utilization.
E. Mannie et. al. Internet-Draft February 2003 45
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
- Sending preemptable excess traffic on recovery resources is a - Sending preemptable excess traffic on recovery resources is a
valuable feature for operators. valuable feature for operators.
13.1. Protection escalation across domains and layers 13.1. Protection escalation across domains and layers
To describe the P&R architecture, one must consider two dimensions To describe the P&R architecture, one must consider two dimensions
of hierarchy [TE-RESTORE]: of hierarchy [TE-RESTORE]:
- A horizontal hierarchy consisting of multiple P&R domains, which - A horizontal hierarchy consisting of multiple P&R domains, which
is important in an LSP based protection scheme. The scope of P&R is important in an LSP based protection scheme. The scope of P&R
E. Mannie et. al. Internet-Draft September 2002 43
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
may extend over a link (or span), an administrative domain or sub- may extend over a link (or span), an administrative domain or sub-
network, an entire LSP. network, an entire LSP.
An administrative domain may consist of a single P&R domain or as An administrative domain may consist of a single P&R domain or as
a concatenation of several smaller P&R domains. The operator can a concatenation of several smaller P&R domains. The operator can
configure P&R domains, based on customers' requirements, and on configure P&R domains, based on customers' requirements, and on
network topology and traffic engineering constraints. network topology and traffic engineering constraints.
- A vertical hierarchy consisting of multiple layers of P&R with - A vertical hierarchy consisting of multiple layers of P&R with
varying granularities (packet flows, STS trails, lightpaths, varying granularities (packet flows, STS trails, lightpaths,
skipping to change at line 2454 skipping to change at line 2570
The choice of a P&R scheme is a tradeoff between network utilization The choice of a P&R scheme is a tradeoff between network utilization
(cost) and service interruption time. In light of this tradeoff, (cost) and service interruption time. In light of this tradeoff,
network service providers are expected to support a range of network service providers are expected to support a range of
different service offerings or service levels. different service offerings or service levels.
One can classify LSPs into one of a small set of service levels. One can classify LSPs into one of a small set of service levels.
Among other things, these service levels define the reliability Among other things, these service levels define the reliability
characteristics of the LSP. The service level associated with a characteristics of the LSP. The service level associated with a
given LSP is mapped to one or more P&R schemes during LSP given LSP is mapped to one or more P&R schemes during LSP
establishment. An advantage that mapping is that an LSP may use establishment. An advantage that mapping is that an LSP may use
E. Mannie et. al. Internet-Draft February 2003 46
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
different P&E schemes in different segments of a network (e.g. some different P&E schemes in different segments of a network (e.g. some
links may be span protected, whilst other segments of the LSP may links may be span protected, whilst other segments of the LSP may
utilize ring protection). These details are likely to be service utilize ring protection). These details are likely to be service
provider specific. provider specific.
An alternative to using service levels is for an application to An alternative to using service levels is for an application to
specify the set of specific P&R mechanisms to be used when specify the set of specific P&R mechanisms to be used when
establishing the LSP. This allows greater flexibility in using establishing the LSP. This allows greater flexibility in using
different mechanisms to meet the application requirements. different mechanisms to meet the application requirements.
E. Mannie et. al. Internet-Draft September 2002 44
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
A differentiator between these service levels is service A differentiator between these service levels is service
interruption time in the event of network failures, which is defined interruption time in the event of network failures, which is defined
as the length of time between when a failure occurs and when as the length of time between when a failure occurs and when
connectivity is re-established. The choice of service level (or P&R connectivity is re-established. The choice of service level (or P&R
scheme) should be dictated by the service requirements of different scheme) should be dictated by the service requirements of different
applications. applications.
13.3. Classification of P&R mechanism characteristics 13.3. Classification of P&R mechanism characteristics
The following figure provides a classification of the possible The following figure provides a classification of the possible
skipping to change at line 2511 skipping to change at line 2628
- Fault detection is technology and implementation dependent. In - Fault detection is technology and implementation dependent. In
general, failures are detected by lower layer mechanisms (e.g. general, failures are detected by lower layer mechanisms (e.g.
SONET/SDH, Loss-of-Light (LOL)). When a node detects a failure, an SONET/SDH, Loss-of-Light (LOL)). When a node detects a failure, an
alarm may be passed up to a GMPLS entity, which will take alarm may be passed up to a GMPLS entity, which will take
appropriate actions, or the alarm may be propagated at the lower appropriate actions, or the alarm may be propagated at the lower
layer (e.g. SONET/SDH AIS). layer (e.g. SONET/SDH AIS).
- Fault localization can be done with the help of GMPLS, e.g. using - Fault localization can be done with the help of GMPLS, e.g. using
LMP for fault localization (see section 8.4). LMP for fault localization (see section 8.4).
E. Mannie et. al. Internet-Draft February 2003 47
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
- Fault notification can also be achieved through GMPLS, e.g. using - Fault notification can also be achieved through GMPLS, e.g. using
GMPLS RSVP-TE/CR-LDP notification (see section 9.12). GMPLS RSVP-TE/CR-LDP notification (see section 9.12).
- This section focuses on the different mechanisms available for - This section focuses on the different mechanisms available for
recovery and restoral of traffic once fault detection, recovery and restoral of traffic once fault detection,
localization and notification have taken place. localization and notification have taken place.
E. Mannie et. al. Internet-Draft September 2002 45
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
13.5. Recovery Strategies 13.5. Recovery Strategies
Network P&R techniques can be divided into Protection and Network P&R techniques can be divided into Protection and
Restoration. In protection, resources between the protection Restoration. In protection, resources between the protection
endpoints are established before failure, and connectivity after endpoints are established before failure, and connectivity after
failure is achieved simply by switching performed at the protection failure is achieved simply by switching performed at the protection
end-points. In contrast, restoration uses signaling after failure to end-points. In contrast, restoration uses signaling after failure to
allocate resources along the recovery path. allocate resources along the recovery path.
- Protection aims at extremely fast reaction times and may rely on - Protection aims at extremely fast reaction times and may rely on
skipping to change at line 2568 skipping to change at line 2685
- 1+1 Link Protection: Two pre-provisioned resources are used in - 1+1 Link Protection: Two pre-provisioned resources are used in
parallel. For example, data is transmitted simultaneously on two parallel. For example, data is transmitted simultaneously on two
parallel links and a selector is used at the receiving node to parallel links and a selector is used at the receiving node to
choose the best source. [Mechanisms reference to be added]. choose the best source. [Mechanisms reference to be added].
- 1:N Link Protection: Working and protecting resources (N working, - 1:N Link Protection: Working and protecting resources (N working,
1 backup) are pre-provisioned. If a working resource fails, the 1 backup) are pre-provisioned. If a working resource fails, the
data is switched to the protecting resource, using a coordination data is switched to the protecting resource, using a coordination
mechanism (e.g. in overhead bytes). More generally, N working and mechanism (e.g. in overhead bytes). More generally, N working and
E. Mannie et. al. Internet-Draft February 2003 48
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
M protecting resources can be assigned for M:N link protection. M protecting resources can be assigned for M:N link protection.
[Mechanisms reference to be added]. [Mechanisms reference to be added].
- Enhanced Protection: Various mechanisms such as protection rings - Enhanced Protection: Various mechanisms such as protection rings
can be used to enhance the level of protection beyond single link can be used to enhance the level of protection beyond single link
failures to include the ability to switch around a node failure or failures to include the ability to switch around a node failure or
multiple link failures within a span, based on a pre-established multiple link failures within a span, based on a pre-established
E. Mannie et. al. Internet-Draft September 2002 46
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
topology of protection resources. [Mechanisms reference to be topology of protection resources. [Mechanisms reference to be
added]. added].
- 1+1 LSP Protection: Simultaneous data transmission on working and - 1+1 LSP Protection: Simultaneous data transmission on working and
protecting LSPs and tail-end selection can be applied. [Mechanisms protecting LSPs and tail-end selection can be applied. [Mechanisms
reference to be added]. reference to be added].
13.7. Recovery mechanisms: Restoration schemes 13.7. Recovery mechanisms: Restoration schemes
Restoration is possible thanks to the use of a distributed control Restoration is possible thanks to the use of a distributed control
skipping to change at line 2626 skipping to change at line 2743
- End-to-end LSP restoration with pre-signaled recovery bandwidth - End-to-end LSP restoration with pre-signaled recovery bandwidth
reservation and label pre-selection: An end-to-end restoration reservation and label pre-selection: An end-to-end restoration
path is pre-calculated before failure and a signaling procedure is path is pre-calculated before failure and a signaling procedure is
initiated along this pre-selected path on which bandwidth is initiated along this pre-selected path on which bandwidth is
reserved and labels are selected. Resources reserved on each link reserved and labels are selected. Resources reserved on each link
may be shared across different working LSPs that are not expected may be shared across different working LSPs that are not expected
to fail simultaneously. In networks based on TDM, LSC and FSC to fail simultaneously. In networks based on TDM, LSC and FSC
technology, LSP signaling is used after failure detection to technology, LSP signaling is used after failure detection to
establish cross-connections at the intermediate switches on the establish cross-connections at the intermediate switches on the
E. Mannie et. al. Internet-Draft February 2003 49
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
restoration path using the pre-selected labels. [Mechanisms restoration path using the pre-selected labels. [Mechanisms
reference to be added]. reference to be added].
- Local LSP restoration: the above approaches can be applied on a - Local LSP restoration: the above approaches can be applied on a
local basis rather than end-to-end, in order to reduce recovery local basis rather than end-to-end, in order to reduce recovery
time. [Mechanisms reference to be added]. time. [Mechanisms reference to be added].
E. Mannie et. al. Internet-Draft September 2002 47
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
13.8. Schema selection criteria 13.8. Schema selection criteria
This section discusses criteria that could be used by the operator This section discusses criteria that could be used by the operator
in order to make a choice among the various P&R mechanisms. in order to make a choice among the various P&R mechanisms.
- Robustness: In general, the less pre-planning of the restoration - Robustness: In general, the less pre-planning of the restoration
path, the more robust the restoration scheme is to a variety of path, the more robust the restoration scheme is to a variety of
failures, provided that adequate resources are available. failures, provided that adequate resources are available.
Restoration schemes with pre-planned paths, will not be able to Restoration schemes with pre-planned paths, will not be able to
recover from network failures that simultaneously affect both the recover from network failures that simultaneously affect both the
skipping to change at line 2683 skipping to change at line 2801
restoration route, the more rapid the P&R scheme. Protection restoration route, the more rapid the P&R scheme. Protection
schemes generally recover faster than restoration schemes. schemes generally recover faster than restoration schemes.
Restoration with pre-signaled bandwidth reservation are likely to Restoration with pre-signaled bandwidth reservation are likely to
be (significantly) faster than path restoration with re- be (significantly) faster than path restoration with re-
provisioning, especially because of the elimination of any provisioning, especially because of the elimination of any
crankback. Local restoration will generally be faster than end-to- crankback. Local restoration will generally be faster than end-to-
end schemes. end schemes.
Recovery time objectives for SONET/SDH protection switching (not Recovery time objectives for SONET/SDH protection switching (not
including time to detect failure) are specified in [G.841] at 50 including time to detect failure) are specified in [G.841] at 50
E. Mannie et. al. Internet-Draft February 2003 50
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
ms, taking into account constraints on distance, number of ms, taking into account constraints on distance, number of
connections involved, and in the case of ring enhanced protection, connections involved, and in the case of ring enhanced protection,
number of nodes in the ring. number of nodes in the ring.
Recovery time objectives for restoration mechanisms are being Recovery time objectives for restoration mechanisms are being
defined through a separate effort [TE-RESTORE]. defined through a separate effort [TE-RESTORE].
E. Mannie et. al. Internet-Draft September 2002 48
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
- Resource Sharing: 1+1 and 1:N link and LSP protection require - Resource Sharing: 1+1 and 1:N link and LSP protection require
dedicated recovery paths with limited ability to share resources: dedicated recovery paths with limited ability to share resources:
1+1 allows no sharing, 1:N allows some sharing of protection 1+1 allows no sharing, 1:N allows some sharing of protection
resources and support of extra (preemptable) traffic. Flexibility resources and support of extra (preemptable) traffic. Flexibility
is limited because of topology restrictions, e.g. fixed ring is limited because of topology restrictions, e.g. fixed ring
topology for traditional enhanced protection schemes. topology for traditional enhanced protection schemes.
The degree to which restoration schemes allow sharing amongst The degree to which restoration schemes allow sharing amongst
multiple independent failures is directly dictated by the size of multiple independent failures is directly dictated by the size of
the restoration pool. In restoration schemes with re-provisioning, the restoration pool. In restoration schemes with re-provisioning,
skipping to change at line 2740 skipping to change at line 2859
comprises many different layers of control-plane and data-plane comprises many different layers of control-plane and data-plane
technology, it is important for management interfaces in this area technology, it is important for management interfaces in this area
to be flexible enough to allow the manager to manage GMPLS easily, to be flexible enough to allow the manager to manage GMPLS easily,
and in a standard way. and in a standard way.
14.1. Network Management Systems (NMS) 14.1. Network Management Systems (NMS)
The NMS system should maintain the collective information about each The NMS system should maintain the collective information about each
device within the system. Note that the NMS system may actually be device within the system. Note that the NMS system may actually be
comprised of several distributed applications (i.e.: alarm comprised of several distributed applications (i.e.: alarm
E. Mannie et. al. Internet-Draft February 2003 51
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
aggregators, configuration consoles, polling applications, etc...) aggregators, configuration consoles, polling applications, etc...)
that collectively comprises the SPÆs NMS. In this way, it can make that collectively comprises the SPÆs NMS. In this way, it can make
provisioning and maintenance decisions with the full knowledge of provisioning and maintenance decisions with the full knowledge of
the entire SP network. Configuration or provisioning information the entire SP network. Configuration or provisioning information
(i.e.: requests for new services) could be entered into the NMS and (i.e.: requests for new services) could be entered into the NMS and
subsequently distributed via SNMP to the remote devices, making the subsequently distributed via SNMP to the remote devices, making the
SPÆs job of managing the network much more compact and effortless SPÆs job of managing the network much more compact and effortless
E. Mannie et. al. Internet-Draft September 2002 49
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
than having to manage each device individually (i.e.: via CLI). than having to manage each device individually (i.e.: via CLI).
Security and access control can be achieved through the use of Security and access control can be achieved through the use of
SNMPv3 and the View Access Control Model [SNMPv3VACM]. This approach SNMPv3 and the View Access Control Model [SNMPv3VACM]. This approach
can be very effectively used within an SP network, since the SP has can be very effectively used within an SP network, since the SP has
access to and control over all devices within its domain. access to and control over all devices within its domain.
Standardized MIBs will need to be developed before this approach can Standardized MIBs will need to be developed before this approach can
be used ubiquitously to provision, configure and monitor devices in be used ubiquitously to provision, configure and monitor devices in
non-heterogeneous networks or across SP boundaries. non-heterogeneous networks or across SP boundaries.
14.2. Management Information Base (MIB) 14.2. Management Information Base (MIB)
skipping to change at line 2797 skipping to change at line 2916
plane topology that will mimic the data plane topology. Furthermore, plane topology that will mimic the data plane topology. Furthermore,
such tools provide network reachability information. The GMPLS such tools provide network reachability information. The GMPLS
control protocols will need to expose certain pieces of information control protocols will need to expose certain pieces of information
in order for these tools to function properly and to provide in order for these tools to function properly and to provide
information germane to GMPLS. These tools should be made available information germane to GMPLS. These tools should be made available
via the CLI. These tools should also be made available for remote via the CLI. These tools should also be made available for remote
invocation via the SNMP interface [RFC2925]. invocation via the SNMP interface [RFC2925].
14.4. Fault Correlation Between Multiple Layers 14.4. Fault Correlation Between Multiple Layers
E. Mannie et. al. Internet-Draft February 2003 52
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Due to the nature of GMPLS and the fact that potential layers may be Due to the nature of GMPLS and the fact that potential layers may be
involved in the control and transmission of GMPLS data and control involved in the control and transmission of GMPLS data and control
information, it is therefore required that a fault in one layer be information, it is therefore required that a fault in one layer be
passed to the adjacent higher and lower layers in an effort to passed to the adjacent higher and lower layers in an effort to
notify them of the fault. However, due to nature of these many notify them of the fault. However, due to nature of these many
layers, it is possible and even probable, that hundreds or even layers, it is possible and even probable, that hundreds or even
thousands of notifications may need to transpire between layers. thousands of notifications may need to transpire between layers.
This is undesirable for several reasons. First, these notifications This is undesirable for several reasons. First, these notifications
E. Mannie et. al. Internet-Draft September 2002 50
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
will overwhelm the device. Second, if the device(s) are programmed will overwhelm the device. Second, if the device(s) are programmed
to emit SNMP Notifications [RFC1901] then the large number of to emit SNMP Notifications [RFC1901] then the large number of
notifications the device may attempt to emit may overwhelm the notifications the device may attempt to emit may overwhelm the
network with a storm of notifications. Furthermore, even if the network with a storm of notifications. Furthermore, even if the
device emits the notifications, the NMS that must process these device emits the notifications, the NMS that must process these
notifications will either be overwhelmed, or will be processing notifications will either be overwhelmed, or will be processing
redundant information. That is, if 1000 interfaces at layer B are redundant information. That is, if 1000 interfaces at layer B are
stacked above a single interface below it at layer A, and the stacked above a single interface below it at layer A, and the
interface at A goes down, the interfaces at layer B should not emit interface at A goes down, the interfaces at layer B should not emit
notifications. Instead, the interface at layer A should emit a notifications. Instead, the interface at layer A should emit a
skipping to change at line 2855 skipping to change at line 2973
that exchange GMPLS control messages as well as the exposure of the that exchange GMPLS control messages as well as the exposure of the
control channel to third parties. In general, a network node may control channel to third parties. In general, a network node may
apply more relaxed security requirements when exchanging GMPLS apply more relaxed security requirements when exchanging GMPLS
control messages with nodes under the same administrative domain control messages with nodes under the same administrative domain
than when talking to nodes in a different domain. In this respect, than when talking to nodes in a different domain. In this respect,
network to user (UNI) and network-to-network interfaces are expected network to user (UNI) and network-to-network interfaces are expected
to have higher security requirements than node-to-node interfaces. to have higher security requirements than node-to-node interfaces.
Security mechanisms can provide two main properties: authentication Security mechanisms can provide two main properties: authentication
and confidentiality. Authentication can provide origin verification, and confidentiality. Authentication can provide origin verification,
E. Mannie et. al. Internet-Draft February 2003 53
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
message integrity and replay protection, while confidentiality message integrity and replay protection, while confidentiality
ensures that a third party cannot decipher the contents of a ensures that a third party cannot decipher the contents of a
message. In situations where GMPLS deployment requires primarily message. In situations where GMPLS deployment requires primarily
authentication, the respective authentication mechanisms of the authentication, the respective authentication mechanisms of the
GMPLS component protocols may be used ([RFC2747], [LDP], [RFC2385], GMPLS component protocols may be used ([RFC2747], [RFC3036],
[LMP]). Additionally, the IPSEC suite of protocols ([RFC2402], [RFC2385], [LMP]). Additionally, the IPSEC suite of protocols
[RFC2406], [RFC2409]) may be used to provide authentication, ([RFC2402], [RFC2406], [RFC2409]) may be used to provide
confidentiality or both, for a GMPLS control channel; this option authentication, confidentiality or both, for a GMPLS control
channel; this option offers the benefit of combined protection of
E. Mannie et. al. Internet-Draft September 2002 51 all GMPLS component protocols.
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
offers the benefit of combined protection of all GMPLS component
protocols.
Note however that GMPLS itself introduces no new security Note however that GMPLS itself introduces no new security
considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP), considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP),
routing protocols (OSPF-TE, IS-IS-TE) or network management routing protocols (OSPF-TE, IS-IS-TE) or network management
protocols (SNMP). protocols (SNMP).
16. Acknowledgements 16. Acknowledgements
This draft is the work of numerous authors and consists of a This draft is the work of numerous authors and consists of a
composition of a number of previous drafts in this area. composition of a number of previous drafts in this area.
skipping to change at line 2906 skipping to change at line 3024
[CR-LDP-GMPLS] draft-ietf-mpls-generalized-cr-ldp-05.txt [CR-LDP-GMPLS] draft-ietf-mpls-generalized-cr-ldp-05.txt
Generalized MPLS Signaling - CR-LDP Extensions Generalized MPLS Signaling - CR-LDP Extensions
[SONETSDH-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-03.txt [SONETSDH-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
GMPLS Extensions for SONET and SDH Control GMPLS Extensions for SONET and SDH Control
[SONETSDH-EXT-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-extensions- [SONETSDH-EXT-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-extensions-
01.txt. GMPLS Extensions to Control Non-Standard 01.txt. GMPLS Extensions to Control Non-Standard
SONET and SDH Features SONET and SDH Features
[G709-GMPLS] draft-fontana-ccamp-gmpls-g709-01.txt [G709-GMPLS] draft-ietf-ccamp-gmpls-g709-01.txt
GMPLS Signaling Extensions for G.709 Optical GMPLS Signaling Extensions for G.709 Optical
Transport Networks Control Transport Networks Control
[LMP] draft-ietf-mpls-lmp-02.txt [LMP] draft-ietf-mpls-lmp-02.txt
Link Management Protocol (LMP) Link Management Protocol (LMP)
E. Mannie et. al. Internet-Draft February 2003 54
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
[LMP-WDM] draft-ietf-ccamp-lmp-wdm-00.txt [LMP-WDM] draft-ietf-ccamp-lmp-wdm-00.txt
LMP for WDM Optical Line Systems (LMP-WDM) LMP for WDM Optical Line Systems (LMP-WDM)
[HIERARCHY] draft-ietf-mpls-lsp-hierarchy-04.txt [HIERARCHY] draft-ietf-mpls-lsp-hierarchy-04.txt
LSP Hierarchy with MPLS TE LSP Hierarchy with MPLS TE
[RSVP-TE-UNNUM] draft-ietf-mpls-rsvp-unnum-04.txt [RSVP-TE-UNNUM] draft-ietf-mpls-rsvp-unnum-04.txt
Signalling Unnumbered Links in RSVP-TE Signalling Unnumbered Links in RSVP-TE
E. Mannie et. al. Internet-Draft September 2002 52
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
[CR-LDP-UNNUM] draft-ietf-mpls-crldp-unnum-04.txt [CR-LDP-UNNUM] draft-ietf-mpls-crldp-unnum-04.txt
Signalling Unnumbered Links in CR-LDP Signalling Unnumbered Links in CR-LDP
[BUNDLE] draft-ietf-mpls-bundle-01.txt [BUNDLE] draft-ietf-mpls-bundle-01.txt
Link Bundling in MPLS Traffic Engineering Link Bundling in MPLS Traffic Engineering
[GMPLS-ROUTING] draft-ietf-ccamp-gmpls-routing-02.txt [GMPLS-ROUTING] draft-ietf-ccamp-gmpls-routing-02.txt
Routing Extensions in Support of Generalized MPLS Routing Extensions in Support of Generalized MPLS
[OSPF-TE-GMPLS] draft-ietf-ccamp-ospf-gmpls-extensions-04.txt [OSPF-TE-GMPLS] draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
skipping to change at line 2952 skipping to change at line 3070
[RFC1393] G. Malkin, "Traceroute Using an IP Option", IETF [RFC1393] G. Malkin, "Traceroute Using an IP Option", IETF
RFC 1393, January 1993. RFC 1393, January 1993.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based Waldbusser, "Introduction to Community-based
SNMPv2", IETF RFC 1901, January 1996. SNMPv2", IETF RFC 1901, January 1996.
[RFC1902] Case, J., McCloghrie, K., Rose, M., and S. [RFC1902] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Structure of Management Information for Waldbusser, "Structure of Management Information for
Version 2 of the Simple Network Management Protocol Version 2 of the Simple Network Management Protocol
(SNMPv2)", IETF RFC 1901, January 1996. (SNMPv2)", IETF RFC 1902, January 1996.
[RFC1903] Case, J., McCloghrie, K., Rose, M., and S. [RFC1903] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Textual Conventions for Version 2 of the Waldbusser, "Textual Conventions for Version 2 of the
Simple Network Management Protocol (SNMPv2)", Simple Network Management Protocol (SNMPv2)",
IETF RFC 1901, January 1996. IETF RFC 1903, January 1996.
[RFC1904] Case, J., McCloghrie, K., Rose, M., and S. [RFC1904] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Conformance Statements for Version 2 of Waldbusser, "Conformance Statements for Version 2 of
the Simple Network Management Protocol (SNMPv2)", the Simple Network Management Protocol (SNMPv2)",
IETF RFC 1901, January 1996. IETF RFC 1904, January 1996.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version 2 of Waldbusser, "Protocol Operations for Version 2 of
the Simple Network Management Protocol (SNMPv2)", the Simple Network Management Protocol (SNMPv2)",
IETF RFC 1905, January 1996. IETF RFC 1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S.
E. Mannie et. al. Internet-Draft February 2003 55
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
Waldbusser, "Transport Mappings for Version 2 of Waldbusser, "Transport Mappings for Version 2 of
the Simple Network Management Protocol (SNMPv2)", the Simple Network Management Protocol (SNMPv2)",
IETF RFC 1906, January 1996. IETF RFC 1906, January 1996.
[SNMPv3VACM] Wijnen, B., Presuhn, R., and K. McCloghrie, "View- [SNMPv3VACM] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-
based Access Control Model (VACM) for the Simple based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP)", IETF RFC 2575, Network Management Protocol (SNMP)", IETF RFC 2575,
April 1999. April 1999.
E. Mannie et. al. Internet-Draft September 2002 53 [RFC1739] Kessler G. and Shepard S., "A Primer On Internet and
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002 TCP/IP Tools", IETF RFC 1739, December 1994.
[RFC1739] G. Kessler, S. Shepard , "A Primer On Internet and [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
TCP/IP Tools", RFC1739, December 1994. Requirement Levels", BCP 14, IETF RFC 2119, March 1997.
[RFC2328] J. Moy, "OSPF Version 2", RFC 2328, Standard [RFC2328] J. Moy, "OSPF Version 2", IETF RFC 2328, Standard
Track, April 1998. Track, April 1998.
[RFC2370] R. Coltun, "The OSPF Opaque LSA Option", RFC 2370 [RFC2370] R. Coltun, "The OSPF Opaque LSA Option", IETF RFC 2370
Standard Track, July 1998. Standard Track, July 1998.
[RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP [RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP
MD5 Signature Option," IETF RFC 2385. MD5 Signature Option", IETF RFC 2385, August 1998.
[RFC2402] S. Kent and R. Atkinson, "IP Authentication Header," [RFC2402] S. Kent and R. Atkinson, "IP Authentication Header",
RFC 2402. IETF RFC 2402, November 1998.
[RFC2406] S. Kent and R. Atkinson, "IP Encapsulating Security [RFC2406] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload (ESP)," IETF RFC 2406. Payload (ESP)", IETF RFC 2406, November 1998.
[RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange
(IKE)", IETF RFC 2409. (IKE)", IETF RFC 2409, November 1998.
[RFC2747] F. Baker et al., "RSVP Cryptographic Authentication", [RFC2747] F. Baker et al., "RSVP Cryptographic Authentication",
IETF RFC 2747. IETF RFC 2747, January 2000.
[RFC2925] K. White, "Definitions of Managed Objects for Remote [RFC2925] K. White, "Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations", IETF RFC Ping, Traceroute, and Lookup Operations", IETF RFC
2925, September 2000. 2925, September 2000.
[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol
Label Switching Architecture", IETF RFC 3031, January Label Switching Architecture", IETF RFC 3031, January
2001. 2001.
[RFC3032] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. [RFC3032] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D.
Farinacci, T. Li, A. Conta, " MPLS Label Stack Farinacci, T. Li, A. Conta, " MPLS Label Stack
Encoding", IETF RFC 3032, January 2001. Encoding", IETF RFC 3032, January 2001.
[LPD] L. Andersson, P. Doolan, N. Feldman, A. Fredette, [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette,
B. Thomas, "LDP Specification", IETF RFC 3036, January B. Thomas, "LDP Specification", IETF RFC 3036, January
2001. 2001.
[OSPF-TE] D. Katz, D. Yeung, and K. Kompella, "Traffic [OSPF-TE] D. Katz, D. Yeung, and K. Kompella, "Traffic
Engineering Extensions to OSPF", draft-katz-yeung-ospf- Engineering Extensions to OSPF", draft-katz-yeung-ospf-
traffic-05.txt.
E. Mannie et. al. Internet-Draft February 2003 56
draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
traffic-06.txt.
[MPLS-TEO] D. Awduche et al., "Multi-Protocol Lambda Switching: [MPLS-TEO] D. Awduche et al., "Multi-Protocol Lambda Switching:
Combining MPLS Traffic Engineering Control With Optical Combining MPLS Traffic Engineering Control With Optical
Crossconnects," Internet Draft, Work in Progress, Crossconnects", Internet Draft, Work in Progress,
draft-awduche-mpls-te-optical-03.txt, April 2001. draft-awduche-mpls-te-optical-03.txt, April 2001.
[G.841] ITU-T Recommendation G.841, "Types and Characteristics [G.841] ITU-T Recommendation G.841, "Types and Characteristics
of SDH Network Protection Architectures," July 1995. of SDH Network Protection Architectures", October 1998.
E. Mannie et. al. Internet-Draft September 2002 54
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
[ANSI-T1.105] "Synchronous Optical Network (SONET): Basic [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and Description Including Multiplex Structure, Rates, and
Formats" ANSI T1.105, 2000. Formats", ANSI T1.105, 2000.
[TE-RESTORE] W. Lai, D. McDysan, J. Boyle, et al, "Network Hierarchy [TE-RESTORE] W. Lai, D. McDysan, J. Boyle, et al, "Network Hierarchy
and Multi-layer Survivability", Internet Draft, Work in and Multi-layer Survivability", Internet Draft, Work in
Progress, draft-team-tewg-restore-hierarchy-00.txt, Progress, draft-ietf-tewg-restore-hierarchy-00.txt,
July 2001. October 2001.
[MPLS-RECOVERY] V. Sharma and F. Hellstrand (Editors), "A Framework [MPLS-RECOVERY] V. Sharma and F. Hellstrand (Editors), "A Framework
for MPLS Recovery", Internet Draft, Work in Progress, for MPLS Recovery", Internet Draft, Work in Progress,
draft-ietf-mpls-recovery-frmwrk-03.txt, July 2001. draft-ietf-mpls-recovery-frmwrk-06.txt, July 2002.
[SDH/SONET-GMPLS-FRAMEWORK] G. Bernstein, E. Mannie, V. Sharma, [SDH/SONET-GMPLS-FRAMEWORK] G. Bernstein, E. Mannie, V. Sharma,
"Framework for GMPLS-based Control of SDH/SONET "Framework for GMPLS-based Control of SDH/SONET
Networks", Internet Draft, Work in Progress, Networks", Internet Draft, Work in Progress,
draft-ccamp-optical-sdhsonet-mpls-control-frmwrk- draft-ietf-ccamp-sdhsonet-control-01.txt, May 2002.
00.txt, February 2002.
[OLI-REQ] A. Fredette (Editor), "Optical Link Interface [OLI-REQ] A. Fredette (Editor), "Optical Link Interface
Requirements", Internet Draft, Work in Progress, Requirements", Internet Draft, Work in Progress,
draft-ietf-ccamp-oli-reqts-00.txt, February 2002. draft-ietf-ccamp-oli-reqts-00.txt, February 2002.
[MANCHESTER] J. Manchester, P. Bonenfant, C. Newton, "The Evolution [MANCHESTER] J. Manchester, P. Bonenfant, C. Newton, "The Evolution
of Transport Network Survivability," IEEE of Transport Network Survivability", IEEE
Communications, August 1999. Communications, August 1999.
18. Author's Addresses 18. Author's Address
Peter Ashwood-Smith Eric Mannie (editor)
Nortel Networks Corp. Ebone (GTS)
P.O. Box 3511 Station C, Terhulpsesteenweg 6A
Ottawa, ON K1Y 4H7 1560 Hoeilaart
Canada Belgium
Phone: +1 613 763 4534 Phone: +32 2 658 56 52
Email: Email: eric.mannie@gts.com
petera@nortelnetworks.com
Daniel O. Awduche Thomas D. Nadeau
Movaz Networks Cisco Systems, Inc.
7296 Jones Branch Drive 250 Apollo Drive
Suite 615 Chelmsford, MA 01824
McLean, VA 22102 USA
USA Phone: +1 978 244 3051
Phone: +1 703 847-7350 Email: tnadeau@cisco.com
Email: awduche@movaz.com
E. Mannie et. al. Internet-Draft September 2002 55
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
Ayan Banerjee Lyndon Ong
Calient Networks Ciena Systems
5853 Rue Ferrari 10480 Ridgeview Ct
San Jose, CA 95138 Cupertino, CA 95014
USA USA
Phone: +1 408 972-3645 Email: lyong@ciena.com
Email: abanerjee@calient.net
Debashis Basak Dimitri Papadimitriou
Accelight Networks Alcatel - IPO NSG
70 Abele Road, Bldg.1200 Francis Wellesplein, 1
Bridgeville, PA 15017 B-2018 Antwerpen
USA Belgium
Phone: +1 412 220-2102 (ext115) Phone: +32 3 240-84-91
email: dbasak@accelight.com Email:
dimitri.papadimitriou@alcatel.be
Lou Berger Dimitrios Pendarakis
Movaz Networks, Inc. Tellium, Inc.
7926 Jones Branch Drive 2 Crescent Place
Suite 615 P.O. Box 901
MCLean VA, 22102 Oceanport, NJ 07757-0901
USA USA
Phone: +1 703 847-1801 Email: DPendarakis@tellium.com
Email: lberger@movaz.com
Greg Bernstein Bala Rajagopalan
Ciena Corporation Tellium, Inc.
10480 Ridgeview Court 2 Crescent Place
Cupertino, CA 94014 P.O. Box 901
USA Oceanport, NJ 07757-0901
Phone: +1 408 366 4713 USA
Email: greg@ciena.com Phone: +1 732 923 4237
Email: braja@tellium.com
Sudheer Dharanikota Yakov Rekhter
Nayna Networks Inc. Juniper
481 Sycamore Drive Email: yakov@juniper.net
Milpitas, CA 95035
USA
Email: sudheer@nayna.com
John Drake Debanjan Saha
Calient Networks Tellium Optical Systems
5853 Rue Ferrari 2 Crescent Place
San Jose, CA 95138 Oceanport, NJ 07757-0901
USA USA
Phone: +1 408 972 3720 Phone: +1 732 923 4264
Email: jdrake@calient.net Email: dsaha@tellium.com
E. Mannie et. al. Internet-Draft September 2002 56
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
Yanhe Fan Hal Sandick
Axiowave Networks, Inc. Nortel Networks
200 Nickerson Road Email:
Marlborough, MA 01752 hsandick@nortelnetworks.com
USA
Phone: +1 774 348 4627
Email: yfan@axiowave.com
Don Fedyk Vishal Sharma
Nortel Networks Corp. Metanoia, Inc.
600 Technology Park Drive 305 Elan Village Lane, Unit
Billerica, MA 01821 121
USA San Jose, CA 95134-2545
Phone: +1-978-288-4506 USA
Email: Phone: +1 408 895 50 30
dwfedyk@nortelnetworks.com Email: vsharma87@yahoo.com
Gert Grammel George Swallow
Alcatel Cisco Systems, Inc.
Via Trento, 30 250 Apollo Drive
20059 Vimercate (Mi) Chelmsford, MA 01824
Italy USA
Email: gert.grammel@alcatel.it Phone: +1 978 244 8143
Email: swallow@cisco.com
Dan Guo Z. Bo Tang
Turin Networks, Inc. Tellium, Inc.
1415 N. McDowell Blvd, 2 Crescent Place
Petaluma, CA 95454 P.O. Box 901
USA Oceanport, NJ 07757-0901
Email: dguo@turinnetworks.com USA
Phone: +1 732 923 4231
Email: btang@tellium.com
Kireeti Kompella Jennifer Yates
Juniper Networks, Inc. AT&T
1194 N. Mathilda Ave. 180 Park Avenue
Sunnyvale, CA 94089 Florham Park, NJ 07932
USA USA
Email: kireeti@juniper.net Email: jyates@research.att.com
Alan Kullberg George R. Young
NetPlane Systems, Inc. Edgeflow
888 Washington 329 March Road
St.Dedham, MA 02026 Ottawa, Ontario, K2K 2E1
USA Canada
Phone: +1 781 251-5319 Email:
Email: akullber@netplane.com george.young@edgeflow.com
E. Mannie et. al. Internet-Draft September 2002 57
draft-ietf-ccamp-gmpls-architecture-02.txt March 2002
Jonathan P. Lang John Yu Eric Mannie
Calient Networks Zaffire Inc. Ebone (GTS)
25 Castilian 2630 Orchard Parkway Terhulpsesteenweg 6A
Goleta, CA 93117 San Jose, CA 95134 1560 Hoeilaart
Email: jplang@calient.net USA Belgium
Email: jzyu@zaffire.com Phone: +32 2 658-5652
Email: eric.mannie@gts.com
Fong Liaw Alex Zinin E. Mannie et. al. Internet-Draft February 2003 57
Zaffire Inc. Nexsi Systems draft-ietf-ccamp-gmpls-architecture-03.txt August 2002
2630 Orchard Parkway 178 East Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: fliaw@zaffire.com
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
skipping to change at line 3233 skipping to change at line 3226
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
E. Mannie et. al. Internet-Draft September 2002 58 E. Mannie et. al. Internet-Draft February 2003 58
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/