draft-ietf-ccamp-gmpls-architecture-05.txt   draft-ietf-ccamp-gmpls-architecture-06.txt 
Network Working Group Eric Mannie - Editor Network Working Group Eric Mannie - Editor
Internet Draft Internet Draft
Category: Standard Track Category: Standard Track
Expiration date: September 2003 March 2003 Expiration date: October 2003 April 2003
Generalized Multi-Protocol Label Switching Architecture Generalized Multi-Protocol Label Switching Architecture
draft-ietf-ccamp-gmpls-architecture-05.txt draft-ietf-ccamp-gmpls-architecture-06.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. all provisions of Section 10 of RFC2026.
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.
skipping to change at line 103 skipping to change at line 103
9.5. Bandwidth Encoding ......................................... 29 9.5. Bandwidth Encoding ......................................... 29
9.6. Generalized Label .......................................... 29 9.6. Generalized Label .......................................... 29
9.7. Waveband Switching ......................................... 30 9.7. Waveband Switching ......................................... 30
9.8. Label Suggestion by the Upstream ........................... 30 9.8. Label Suggestion by the Upstream ........................... 30
9.9. Label Restriction by the Upstream .......................... 31 9.9. Label Restriction by the Upstream .......................... 31
9.10. Bi-directional LSP ........................................ 31 9.10. Bi-directional LSP ........................................ 31
9.11. Bi-directional LSP Contention Resolution .................. 32 9.11. Bi-directional LSP Contention Resolution .................. 32
9.12. Rapid Notification of Failure ............................. 32 9.12. Rapid Notification of Failure ............................. 32
9.13. Link Protection ........................................... 33 9.13. Link Protection ........................................... 33
9.14. Explicit Routing and Explicit Label Control ............... 34 9.14. Explicit Routing and Explicit Label Control ............... 34
9.15. Route Recording ........................................... 34 9.15. Route Recording ........................................... 35
9.16. LSP Modification and LSP Re-routing ....................... 35 9.16. LSP Modification and LSP Re-routing ....................... 35
9.17. LSP Administrative Status Handling ........................ 35 9.17. LSP Administrative Status Handling ........................ 36
E. Mannie (Editor) et al. Standard Track 2 E. Mannie (Editor) et al. Standard Track 2
9.18. Control Channel Separation ................................ 36 9.18. Control Channel Separation ................................ 36
10. Forwarding Adjacencies (FA) ................................. 37 10. Forwarding Adjacencies (FA) ................................. 37
10.1. Routing and Forwarding Adjacencies ........................ 38 10.1. Routing and Forwarding Adjacencies ........................ 38
10.2. Signaling Aspects ......................................... 38 10.2. Signaling Aspects ......................................... 39
10.3. Cascading of Forwarding Adjacencies ....................... 39 10.3. Cascading of Forwarding Adjacencies ....................... 39
11. Routing and Signaling Adjacencies ........................... 39 11. Routing and Signaling Adjacencies ........................... 39
12. Control Plane Fault Handling ................................ 40 12. Control Plane Fault Handling ................................ 40
13. LSP Protection and Restoration .............................. 41 13. LSP Protection and Restoration .............................. 41
13.1. Protection Escalation across Domains and Layers ........... 42 13.1. Protection Escalation across Domains and Layers ........... 42
13.2. Mapping of Services to P&R Resources ...................... 43 13.2. Mapping of Services to P&R Resources ...................... 43
13.3. Classification of P&R Mechanism Characteristics ........... 43 13.3. Classification of P&R Mechanism Characteristics ........... 43
13.4. Different Stages in P&R ................................... 44 13.4. Different Stages in P&R ................................... 44
13.5. Recovery Strategies ....................................... 44 13.5. Recovery Strategies ....................................... 44
13.6. Recovery mechanisms: Protection schemes ................... 45 13.6. Recovery mechanisms: Protection schemes ................... 45
13.7. Recovery mechanisms: Restoration schemes .................. 45 13.7. Recovery mechanisms: Restoration schemes .................. 45
13.8. Schema Selection Criteria ................................. 46 13.8. Schema Selection Criteria ................................. 46
14. Network Management .......................................... 47 14. Network Management .......................................... 48
14.1. Network Management Systems (NMS) .......................... 48 14.1. Network Management Systems (NMS) .......................... 48
14.2. Management Information Base (MIB) ......................... 48 14.2. Management Information Base (MIB) ......................... 48
14.3. Tools ..................................................... 49 14.3. Tools ..................................................... 49
14.4. Fault Correlation Between Multiple Layers ................. 49 14.4. Fault Correlation Between Multiple Layers ................. 49
15. Security Considerations ..................................... 49 15. Security Considerations ..................................... 50
16. Acknowledgements ............................................ 50 16. Acknowledgements ............................................ 51
17. Intellectual Property Considerations ........................ 50 17. Intellectual Property Considerations ........................ 51
18. References .................................................. 51 18. References .................................................. 51
18.1 Normative References ....................................... 51 18.1 Normative References ....................................... 51
18.2 Information References ..................................... 53 18.2 Information References ..................................... 54
19. Author's Address ............................................ 54 19. Author's Address ............................................ 55
20. Contributors ................................................ 54 20. Contributors ................................................ 55
Full Copyright Statement ........................................ 57 Full Copyright Statement ........................................ 57
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 [RFC2119]. this document are to be interpreted as described in [RFC2119].
3. Introduction 3. Introduction
skipping to change at line 535 skipping to change at line 535
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; they are also used to find for IP datagrams with a SPF algorithm; they 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.
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
take advantages of all the valuable developments that took place taking advantage 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).
In an overlay model, each particular non-PSC layer can be seen as a In an overlay model, each particular non-PSC layer can be seen as a
set of Autonomous Systems (ASs) interconnected in an arbitrary way. set of Autonomous Systems (ASs) interconnected in an arbitrary way.
Similarly to the traditional IP routing, each AS is managed by a Similarly to the traditional IP routing, each AS is managed by a
single administrative authority. For instance, an AS can be an single administrative authority. For instance, an AS can be an
SONET/SDH network operated by a given carrier. The set of SONET/SDH network operated by a given carrier. The set of
interconnected ASs can be viewed as SONET/SDH internetworks. interconnected ASs can be viewed as SONET/SDH internetworks.
skipping to change at line 637 skipping to change at line 637
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
separate section. Section 10.
- 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 these properties may be logical link that has TE properties. Some of these properties may be
configured on the advertising LSR, others may be obtained from other configured on the advertising LSR, others may be obtained from other
LSRs by means of some protocol, and yet others may be deduced from LSRs by means of some protocol, and yet others may be deduced from
the component(s) of the TE link. the component(s) of the TE link.
skipping to change at line 1061 skipping to change at line 1061
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 has been (LMP) has been defined to fulfill these operations. LMP has been
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.
In GMPLS, the control channels between two adjacent nodes are no
longer required to use the same physical medium as the data links
between those nodes. Moreover, the control channels that are used to
exchange the GMPLS control-plane information exist independently of
the links they manage. Hence, LMP was designed to manage the data
links, independently of the termination capabilities of those data
links.
Control channel management and link property correlation procedures Control channel management and link property correlation procedures
are mandatory per LMP. Link connectivity verification and fault are mandatory per LMP. Link connectivity verification and fault
management procedures are optional. management procedures are optional.
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
control channels between nodes. Control channels exist independently control channels between nodes. Control channels exist independently
of TE links, and can be used to exchange MPLS control-plane of TE links, and can be used to exchange MPLS control-plane
information such as signaling, routing, and link management information such as signaling, routing, and link management
skipping to change at line 1092 skipping to change at line 1100
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
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
E. Mannie (Editor) et al. Standard Track 20
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
terms of link provisioning and fault isolation. terms of link provisioning and fault isolation.
LMP does not specify the signaling transport mechanism used in the LMP does not specify the signaling transport mechanism used in the
control channel, however it states that messages transported over a control channel, however it states that messages transported over a
control channel must be IP encoded. Furthermore, since the messages control channel must be IP encoded. Furthermore, since the messages
are IP encoded, the link level encoding is not part of LMP. A 32-bit are IP encoded, the link level encoding is not part of LMP. A 32-bit
E. Mannie (Editor) et al. Standard Track 20
non-zero integer Control Channel Identifier (CCId) is assigned to non-zero integer Control Channel Identifier (CCId) is assigned to
each direction of a control channel. each direction of a control channel.
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
skipping to change at line 1147 skipping to change at line 1155
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).
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
E. Mannie (Editor) et al. Standard Track 21
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
signaling. signaling.
The use of this procedure is negotiated as part of the configuration The use of this procedure is negotiated as part of the configuration
exchange that take place during the negotiation phase of the Hello exchange that take place during the negotiation phase of the Hello
protocol. This procedure should be done initially when a data- protocol. This procedure should be done initially when a data-
E. Mannie (Editor) et al. Standard Track 21
bearing link is first established, and subsequently, on a periodic bearing link is first established, and subsequently, on a periodic
basis for all unallocated (free) data-bearing links. basis for all unallocated (free) data-bearing links.
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
skipping to change at line 1203 skipping to change at line 1210
be notified in order to take some actions (fault notification). be notified in order to take some actions (fault notification).
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).
E. Mannie (Editor) et al. Standard Track 22
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
upstream of that fault (i.e. through a fault notification upstream of that fault (i.e. through a fault notification
procedure). procedure).
A downstream LMP neighbor that detects data link failures will send A downstream LMP neighbor that detects data link failures will send
an LMP message to its upstream neighbor notifying it of the failure. an LMP message to its upstream neighbor notifying it of the failure.
When an upstream node receives a failure notification, it can When an upstream node receives a failure notification, it can
E. Mannie (Editor) et al. Standard Track 22
correlate the failure with the corresponding input ports to correlate the failure with the corresponding input ports to
determine if the failure is between the two nodes. Once the failure determine if the failure is between the two nodes. Once the failure
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
skipping to change at line 1259 skipping to change at line 1265
example, the OXC may know that a connection is "up", "down", in a example, the OXC may know that a connection is "up", "down", in a
"testing" mode, or being deleted ("deletion-in-progress"). The OXC "testing" mode, or being deleted ("deletion-in-progress"). The OXC
can use this information to inhibit alarm reporting from the OLS can use this information to inhibit alarm reporting from the OLS
when a connection is "down", "testing", or being deleted. 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
E. Mannie (Editor) et al. Standard Track 23
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
E. Mannie (Editor) et al. Standard Track 23
coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP
sessions are run independently and must be maintained separately. sessions are run independently and must be maintained separately.
One critical requirement when running an OXC-OLS LMP session is the One critical requirement when running an OXC-OLS LMP session is the
ability of the OLS to make a data link transparent when not doing ability of the OLS to make a data link transparent when not doing
the verification procedure. This is because the same data link may the verification procedure. This is because the same data link may
be verified between OXC-OLS and between OXC-OXC. The verification be verified between OXC-OLS and between OXC-OXC. The verification
procedure of LMP is used to coordinate the Test procedure (and hence procedure of LMP is used to coordinate the Test procedure (and hence
the transparency/opaqueness of the data links). To maintain the transparency/opaqueness of the data links). To maintain
independence between the sessions, it must be possible for the LMP independence between the sessions, it must be possible for the LMP
sessions to come up in any order. In particular, it must be possible sessions to come up in any order. In particular, it must be possible
skipping to change at line 1316 skipping to change at line 1322
- Ingress initiated ordered control. - Ingress initiated ordered control.
- 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:
E. Mannie (Editor) et al. Standard Track 24
1. A new generic label request format. 1. A new generic label request format.
2. Labels for TDM, LSC and FSC interfaces, generically known as 2. Labels for TDM, LSC and FSC interfaces, generically known as
Generalized Label. Generalized Label.
3. Waveband switching support. 3. Waveband switching support.
4. Label suggestion by the upstream for optimization purposes 4. Label suggestion by the upstream for optimization purposes
(e.g. latency). (e.g. latency).
5. Label restriction by the upstream to support some optical 5. Label restriction by the upstream to support some optical
E. Mannie (Editor) et al. Standard Track 24
constraints. constraints.
6. Bi-directional LSP establishment with contention resolution. 6. Bi-directional LSP establishment with contention 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.
12. Control channel separation. 12. Control channel separation.
skipping to change at line 1371 skipping to change at line 1376
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
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
E. Mannie (Editor) et al. Standard Track 25
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.
9.1. Overview: How to Request an LSP 9.1. Overview: How to Request an LSP
A TDM, LSC or FSC LSP is established by sending a PATH/Label Request A TDM, LSC or FSC LSP is established by sending a PATH/Label Request
message downstream to the destination. This message contains a message downstream to the destination. This message contains a
Generalized Label Request with the type of LSP (i.e. the layer Generalized Label Request with the type of LSP (i.e. the layer
E. Mannie (Editor) et al. Standard Track 25
concerned), and its payload type. An Explicit Route Object (ERO) is concerned), and its payload type. An Explicit Route Object (ERO) is
also normally added to the message, but this can be added and/or also normally added to the message, but this can be added and/or
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
SONET/SDH LSP. For some other technology there be could just one SONET/SDH 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
skipping to change at line 1427 skipping to change at line 1432
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 [GMPLS-SONET-SDH]). concatenated signal (given an order specified in [GMPLS-SONET-SDH]).
In case of SONET/SDH "multiplication", i.e. co-routing of circuits In case of SONET/SDH "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
E. Mannie (Editor) et al. Standard Track 26
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.
Only one label request can be used per message, so a single LSP can Only one label request can be used per message, so a single LSP can
be requested at a time per signaling message. be requested at a time per signaling message.
The Generalized Label Request gives three major characteristics The Generalized Label Request gives three major characteristics
(parameters) required to support the LSP being requested: the LSP (parameters) required to support the LSP being requested: the LSP
E. Mannie (Editor) et al. Standard Track 26
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.
skipping to change at line 1483 skipping to change at line 1487
defined in the future for photonic (all optical) switching. defined in the future for photonic (all optical) switching.
9.3. SONET/SDH Traffic Parameters 9.3. SONET/SDH Traffic Parameters
The GMPLS SONET/SDH traffic parameters [GMPLS-SONET-SDH] specify a The GMPLS SONET/SDH traffic parameters [GMPLS-SONET-SDH] 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). G.707).
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,
E. Mannie (Editor) et al. Standard Track 27
VC-4, STS-3c, etc. Several transforms can then be applied VC-4, STS-3c, etc. Several transforms can then be applied
successively on the elementary Signal to build the final signal successively on the elementary Signal to build the final signal
being actually requested for the LSP. being actually requested for the LSP.
These transforms are the contiguous concatenation, the virtual These transforms are the contiguous concatenation, the virtual
concatenation, the transparency and the multiplication. Each one is concatenation, the transparency and the multiplication. Each one is
optional. They must be applied strictly in the following order: optional. They must be applied strictly in the following order:
E. Mannie (Editor) et al. Standard Track 27
- 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.
- Fourth, a multiplication can be optionally applied either directly - Fourth, a multiplication can be optionally applied either directly
skipping to change at line 1538 skipping to change at line 1543
occurs at two specific sub-layers: at the OCh (Optical Channel) occurs at two specific sub-layers: at the OCh (Optical Channel)
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 denote ODUs at different layer. The ODUk notation is used to denote ODUs at different
bandwidths. bandwidths.
The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful The GMPLS G.709 traffic parameters [GMPLS-G709] 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
E. Mannie (Editor) et al. Standard Track 28
Gbps, etc. Several transforms can then be applied successively on Gbps, etc. Several transforms can then be applied successively on
the elementary Signal to build the final signal being actually the elementary Signal to build the final signal being actually
requested for the LSP. requested for the LSP.
These transforms are the virtual concatenation and the These transforms are the virtual concatenation and the
multiplication. Each one of these transforms is optional. They must multiplication. Each one of these transforms is optional. They must
be applied strictly in the following order: be applied strictly in the following order:
E. Mannie (Editor) et al. Standard Track 28
- 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.
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.
skipping to change at line 1593 skipping to change at line 1599
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.
E. Mannie (Editor) et al. Standard Track 29
For example, the Generalized Label may identify (a) a single fiber For example, the Generalized Label may identify (a) a single fiber
in a bundle, (b) a single waveband within fiber, (c) a single in a bundle, (b) a single waveband within fiber, (c) a single
wavelength within a waveband (or fiber), or (d) a set of time-slots wavelength within a waveband (or fiber), or (d) a set of time-slots
within a wavelength (or fiber). It may also be a generic MPLS label, within a wavelength (or fiber). It may also be a generic MPLS label,
a Frame Relay label, or an ATM label (VCI/VPI). The format of a a Frame Relay label, or an ATM label (VCI/VPI). The format of a
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 SONET/SDH or a G.709 label or can be more elaborated such as an SONET/SDH or a G.709
label. label.
E. Mannie (Editor) et al. Standard Track 29
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
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
skipping to change at line 1649 skipping to change at line 1655
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.
9.8. Label Suggestion by the Upstream 9.8. Label Suggestion by the Upstream
E. Mannie (Editor) et al. Standard Track 30
GMPLS allows for a label to be optionally suggested by an upstream GMPLS allows for a label to be optionally suggested by an upstream
node. This suggestion may be overridden by a downstream node but in node. This suggestion may be overridden by a downstream node but in
some cases, at the cost of higher LSP setup time. The suggested some cases, at the cost of higher LSP setup time. The suggested
label is valuable when establishing LSPs through certain kinds of label is valuable when establishing LSPs through certain kinds of
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 delay in configuring the switching fabric. For example, micro
mirrors may have to be elevated or moved, and this physical motion mirrors may have to be elevated or moved, and this physical motion
E. Mannie (Editor) et al. Standard Track 30
and subsequent damping takes time. If the labels and hence switching and subsequent damping takes time. If the labels and hence switching
fabric are configured in the reverse direction (the norm), the Resv/ fabric are configured in the reverse direction (the norm), the Resv/
MAPPING message may need to be delayed by 10's of milliseconds per MAPPING message may need to be delayed by 10's of milliseconds per
hop in order to establish a usable forwarding path. It can be 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.
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
skipping to change at line 1704 skipping to change at line 1709
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
jitter) in each direction. jitter) in each direction.
In the remainder of this section, the term "initiator" is used to In the remainder of this section, the term "initiator" is used to
refer to a node that starts the establishment of an LSP; the term refer to a node that starts the establishment of an LSP; the term
E. Mannie (Editor) et al. Standard Track 31
"terminator" is used to refer to the node that is the target of the "terminator" is used to refer to the node that is the target of the
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:
E. Mannie (Editor) et al. Standard Track 31
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
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
skipping to change at line 1758 skipping to change at line 1764
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
requests traveling in opposite directions. This contention occurs requests traveling in opposite directions. This contention occurs
when both sides allocate the same resources (ports) at effectively when both sides allocate the same resources (ports) at effectively
the same time. GMPLS signaling defines a procedure to resolve that the same time. GMPLS signaling defines a procedure to resolve that
contention: the node with the higher node ID will win the contention: the node with the higher node ID will win the
E. Mannie (Editor) et al. Standard Track 32
contention. To reduce the probability of contention, some mechanisms contention. To reduce the probability of contention, some mechanisms
are also suggested. 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 (Editor) et al. Standard Track 32
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 1812 skipping to change at line 1819
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
protection for each link of an LSP. If a particular protection type, protection for each link of an LSP. If a particular protection type,
i.e. 1+1, or 1:N, is requested, then a connection request is i.e. 1+1, or 1:N, is requested, then a connection request is
processed only if the desired protection type can be honored. Note processed only if the desired protection type can be honored. Note
that GMPLS advertises the protection capabilities of a link in the that GMPLS advertises the protection capabilities of a link in the
E. Mannie (Editor) et al. Standard Track 33
routing protocols. Path computation algorithms may consider this routing protocols. Path computation algorithms may consider this
information when computing paths for setting up LSPs. information 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 (Editor) et al. Standard Track 33
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 1867 skipping to change at line 1875
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.
In particular, the explicit label control in the explicit route In particular, the explicit label control in the explicit route
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
E. Mannie (Editor) et al. Standard Track 34
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.
When used together with an optimization algorithm, it can provide When used together with an optimization algorithm, it can provide
very detailed explicit routes, including the label (timeslot) to use very detailed explicit routes, including the label (timeslot) to use
E. Mannie (Editor) et al. Standard Track 34
on a link, in order to minimize the fragmentation of the SONET/SDH on a link, in order to minimize the fragmentation of the SONET/SDH
multiplex on the corresponding interface. multiplex on the 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
in RSVP-TE to function as: in RSVP-TE to function as:
- First, a loop detection mechanism to discover L3 routing loops, or - First, a loop detection mechanism to discover L3 routing loops, or
skipping to change at line 1923 skipping to change at line 1931
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 SONET/SDH circuit characteristics such as the changing some SONET/SDH circuit characteristics such as the
E. Mannie (Editor) et al. Standard Track 35
bandwidth, the protection type, the transparency, the concatenation, bandwidth, the protection type, the transparency, the concatenation,
etc. etc.
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.
E. Mannie (Editor) et al. Standard Track 35
In the first usage, the Admin Status object/TLV is carried in a In the first usage, the Admin Status 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
information indicates the state of the LSP, which include "up" or information indicates the state of the LSP, which include "up" or
"down", if it in a "testing" mode, and if deletion is in progress. "down", if it in a "testing" mode, and if deletion is in progress.
Based on that administrative status, a node can take local Based on that administrative status, a node can take local
decisions, like inhibit alarm reporting when an LSP is in "down" or decisions, like inhibit alarm reporting when an LSP is in "down" or
"testing" states, or report alarms associated with the connection at "testing" states, or report alarms associated with the connection at
a priority equal to or less than "Non service affecting". a priority equal to or less than "Non service affecting".
skipping to change at line 1979 skipping to change at line 1988
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 reason, e.g. when the data channel cannot carry in- band for various reason, e.g. when the data channel cannot carry in-
band control information. This issue was even originally introduced band control information. This issue was even originally introduced
to MPLS in the context of link bundling. to MPLS in the context of link bundling.
E. Mannie (Editor) et al. Standard Track 36
In traditional MPLS, there is an implicit one-to-one association of In traditional MPLS, there is an implicit one-to-one association of
a control channel to a data channel. When such an association is a 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
E. Mannie (Editor) et al. Standard Track 36
interface identification information. GMPLS allows the use of a interface identification information. GMPLS allows the use of a
number of interface identification schemes including IPv4 or IPv6 number of interface identification schemes including IPv4 or IPv6
addresses, interface indexes (for unnumbered interfaces) and addresses, interface indexes (for unnumbered interfaces) and
component interfaces (for bundled interfaces), unnumbered bundled component interfaces (for bundled interfaces), unnumbered bundled
interfaces are also supported. interfaces are also supported.
The choice of the data interface to use is always made by the sender The choice of the data interface to use is always made by the sender
of the Path/Label Request message, and indicated by including the of the Path/Label Request message, and indicated by including the
data channel's interface identifier in the message using a new data channel's interface identifier in the message using a new
RSVP_HOP object sub-type/Interface TLV. RSVP_HOP object sub-type/Interface TLV.
skipping to change at line 2034 skipping to change at line 2042
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
E. Mannie (Editor) et al. Standard Track 37
computation, and (d) nesting of LSPs originated by other LSRs into computation, and (d) nesting of LSPs originated by other LSRs into
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).
ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs
just as it floods the information about any other links. just as it floods the information about any other links.
Consequently to this flooding, an LSR has in its TE link state Consequently to this flooding, an LSR has in its TE link state
database the information about not just conventional links, but FAs database the information about not just conventional links, but FAs
as well. as well.
E. Mannie (Editor) et al. Standard Track 37
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.
skipping to change at line 2089 skipping to change at line 2098
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
establishing ISIS/OSPF peering relation between the routers at the establishing ISIS/OSPF peering relation between the routers at the
ends of the adjacency. ends of the adjacency.
LSP hierarchy could exist both with the peer and with the overlay LSP hierarchy could exist both with the peer and with the overlay
models. With the peer model, the LSP hierarchy is realized via FAs models. With the peer model, the LSP hierarchy is realized via FAs
E. Mannie (Editor) et al. Standard Track 38
and an LSP is both created and used as a TE link by exactly the same and an LSP is both created and used as a TE link by exactly the same
instance of the control plane. Creating LSP hierarchies with instance of the control plane. Creating LSP hierarchies with
overlays doesn't involve the concept of FA. With the overlay model overlays doesn't involve the concept of FA. With the overlay model
an LSP created (and maintained) by one instance of the GMPLS control an LSP created (and maintained) by one instance of the GMPLS control
plane is used as a TE link by another instance of the GMPLS control plane is used as a TE link by another instance of the GMPLS control
plane. Moreover, the nodes using a TE link are expected to have a plane. Moreover, the nodes using a TE link are expected to have a
routing and signaling adjacency. routing and signaling adjacency.
10.2. Signaling Aspects 10.2. Signaling Aspects
E. Mannie (Editor) et al. Standard Track 38
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
skipping to change at line 2143 skipping to change at line 2153
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
Hellos. Hellos.
E. Mannie (Editor) et al. Standard Track 39
By definition, a Forwarding Adjacency (FA) is a TE Link between two By definition, a Forwarding Adjacency (FA) is a TE Link between two
GMPLS nodes whose path transits one or more other (G)MPLS nodes in GMPLS nodes whose path transits one or more other (G)MPLS nodes in
the same instance of the (G)MPLS control plane. If two nodes have the same instance of the (G)MPLS control plane. If two nodes have
one or more non-FA TE Links between them, these two nodes are one or more non-FA TE Links between them, these two nodes are
expected (although not required) to have a routing adjacency. If two expected (although not required) to have a routing adjacency. If two
nodes do not have any non-FA TE Links between them, it is expected nodes do not have any non-FA TE Links between them, it is expected
(although not required) that these two nodes would not have a (although not required) that these two nodes would not have a
routing adjacency. To state the obvious, if the TE links between two routing adjacency. To state the obvious, if the TE links between two
nodes are to be used for establishing LSPs, the two nodes must have nodes are to be used for establishing LSPs, the two nodes must have
a signaling adjacency. a signaling adjacency.
E. Mannie (Editor) et al. Standard Track 39
If one wants to establish routing and/or signaling adjacency between If one wants to establish routing and/or signaling adjacency between
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 frame/ and signaling adjacencies requires exchanging data on a per frame/
skipping to change at line 2198 skipping to change at line 2208
12. Control Plane Fault Handling 12. Control Plane Fault Handling
Two major types of faults can impact a control plane. The first, Two major types of faults can impact a control plane. The first,
referred to as control channel fault, relates to the case where referred to as control channel fault, relates to the case where
control communication is lost between two neighboring nodes. If the control communication is lost between two neighboring nodes. If the
control channel is embedded with the data channel, data channel control channel is embedded with the data channel, data channel
recovery procedure should solve the problem. If the control channel recovery procedure should solve the problem. If the control channel
is independent of the data channel, additional procedures are is independent of the data channel, additional procedures are
required to recover from that problem. required to recover from that problem.
E. Mannie (Editor) et al. Standard Track 40
The second, referred to as nodal faults, relates to the case where The second, referred to as nodal faults, relates to the case where
node loses its control state (e.g., after a restart) but does not node loses its control state (e.g., after a restart) but does not
loose its data forwarding state. loose its data forwarding state.
In transport networks, such types of control plane faults should not In transport networks, such types of control plane faults should not
have service impact on the existing connections. Under such have service impact on the existing connections. Under such
circumstances, a mechanism must exist to detect a control circumstances, a mechanism must exist to detect a control
communication failure and a recovery procedure must guarantee communication failure and a recovery procedure must guarantee
connection integrity at both ends of the control channel. connection integrity at both ends of the control channel.
E. Mannie (Editor) et al. Standard Track 40
For a control channel fault, once communication is restored routing For a control channel fault, once communication is restored routing
protocols are naturally able to recover but the underlying signaling protocols are naturally able to recover but the underlying signaling
protocols must indicate that the nodes have maintained their state protocols must indicate that the nodes have maintained their state
through the failure. The signaling protocol must also ensure that through the failure. The signaling protocol must also ensure that
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 loses most of For a nodal fault, a node's control plane restarts and loses most of
its state information. In this case, both upstream and downstream its state information. In this case, both upstream and downstream
nodes must synchronize their state information with the restarted nodes must synchronize their state information with the restarted
skipping to change at line 2252 skipping to change at line 2262
happens in the data/transport plane. Section 11 deals with control happens in the data/transport plane. Section 11 deals with control
plane fault handling for nodal and control channel faults. plane fault handling for nodal and control channel faults.
- This section focuses on P&R at the TDM, LSC and FSC layers. There - This section focuses on P&R at the TDM, LSC and FSC layers. There
are specific P&R requirements at these layers not present at the are specific P&R requirements at these layers not present at the
PSC layer. PSC layer.
- This section focuses on intra-area P&R as opposed to inter-area - This section focuses on intra-area P&R as opposed to inter-area
P&R and even inter-domain P&R. Note that P&R can even be more P&R and even inter-domain P&R. Note that P&R can even be more
restricted, e.g. to a collection of like customer equipment, or a restricted, e.g. to a collection of like customer equipment, or a
E. Mannie (Editor) et al. Standard Track 41
collection of equipment of like capabilities, in one single collection of equipment of like capabilities, in one single
routing area. routing area.
- This section focuses on intra-layer P&R (horizontal hierarchy as - This section focuses on intra-layer P&R (horizontal hierarchy as
defined in [RFC3386]) as opposed to the inter-layer P&R (vertical defined in [RFC3386]) as opposed to the inter-layer P&R (vertical
hierarchy). hierarchy).
- P&R mechanisms are in general designed to handle single failures, - P&R mechanisms are in general designed to handle single failures,
which makes SRLG diversity a necessity. Recovery from multiple which makes SRLG diversity a necessity. Recovery from multiple
failures requires further study. failures requires further study.
E. Mannie (Editor) et al. Standard Track 41
- Both mesh and ring-like topologies are supported. - Both mesh and ring-like topologies are supported.
In the following, we assume that: In the following, we assume that:
- 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 (thus used) or at least logically reserved (whether used allocated (thus used) or at least logically reserved (whether used
or not by preemptable extra traffic but unavailable anyway for or not by preemptable extra traffic but unavailable anyway for
regular working traffic). regular working traffic).
skipping to change at line 2307 skipping to change at line 2318
fibers, etc). fibers, etc).
In the absence of adequate P&R coordination, a fault may propagate In the absence of adequate P&R coordination, a fault may propagate
from one level to the next within a P&R hierarchy. It can lead to from one level to the next within a P&R hierarchy. It can lead to
"collisions" and simultaneous recovery actions may lead to race "collisions" and simultaneous recovery actions may lead to race
conditions, reduced resource utilization, or instabilities conditions, reduced resource utilization, or instabilities
[MANCHESTER]. Thus, a consistent escalation strategy is needed to [MANCHESTER]. Thus, a consistent escalation strategy is needed to
coordinate recovery across domains and layers. The fact that GMPLS coordinate recovery across domains and layers. The fact that GMPLS
can be used at different layers could simplify this coordination. can be used at different layers could simplify this coordination.
E. Mannie (Editor) et al. Standard Track 42
There are two types of escalation strategies: bottom-up and top- There are two types of escalation strategies: bottom-up and top-
down. The bottom-up approach assumes that "lower-level" recovery down. The bottom-up approach assumes that "lower-level" recovery
schemes are more expedient. Therefore we can inhibit or hold off schemes are more expedient. Therefore we can inhibit or hold off
higher-level P&R. The Top-down approach attempts service P&R at higher-level P&R. The Top-down approach attempts service P&R at
the higher levels before invoking "lower level" P&R. Higher-layer the higher levels before invoking "lower level" P&R. Higher-layer
P&R is service selective, and permits "per-CoS" or "per-LSP" re- P&R is service selective, and permits "per-CoS" or "per-LSP" re-
routing. routing.
Service Level Agreements (SLAs) between network operators and their Service Level Agreements (SLAs) between network operators and their
clients are needed to determine the necessary time scales for P&R at clients are needed to determine the necessary time scales for P&R at
each layer and at each domain. each layer and at each domain.
E. Mannie (Editor) et al. Standard Track 42
13.2. Mapping of Services to P&R Resources 13.2. Mapping of Services to P&R Resources
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
skipping to change at line 2358 skipping to change at line 2368
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
provisioning types of recovery LSPs, and of the levels of provisioning types of recovery LSPs, and of the levels of
overbooking that is possible for them. overbooking that is possible for them.
+-Computed on +-Established +-Resources pre- +-Computed on +-Established +-Resources pre-
| demand | on demand | allocated | demand | on demand | allocated
| | |
Recovery LSP | | | Recovery LSP | | |
Provisioning -+-Pre computed +-Pre established +-Resources allocated Provisioning -+-Pre computed +-Pre established +-Resources allocated
on demand on demand
E. Mannie (Editor) et al. Standard Track 43
+--- Dedicated (1:1, 1+1) +--- Dedicated (1:1, 1+1)
| |
| |
+--- Shared (1:N, Ring, Shared mesh) +--- Shared (1:N, Ring, Shared mesh)
| |
Level of | Level of |
Overbooking ---+--- Best effort Overbooking ---+--- Best effort
E. Mannie (Editor) et al. Standard Track 43
13.4. Different Stages in P&R 13.4. Different Stages in P&R
Recovery from a network fault or impairment takes place in several Recovery from a network fault or impairment takes place in several
stages as discussed in [RFC3469], including fault detection, fault stages as discussed in [RFC3469], including fault detection, fault
localization, notification, recovery (i.e. the P&R itself) and localization, notification, recovery (i.e. the P&R itself) and
reversion of traffic (i.e. returning the traffic to the original reversion of traffic (i.e. returning the traffic to the original
working LSP or to a new one). working LSP or to a new one).
- 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.
skipping to change at line 2417 skipping to change at line 2427
the use of overhead control fields for achieving end-point the use of overhead control fields for achieving end-point
coordination. Protection for SONET/SDH networks is described in coordination. Protection for SONET/SDH networks is described in
[ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be [ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be
further classified by the level of redundancy and sharing. further classified by the level of redundancy and sharing.
- Restoration mechanisms rely on signaling protocols to coordinate - Restoration mechanisms rely on signaling protocols to coordinate
switching actions during recovery, and may involve simple re- switching actions during recovery, and may involve simple re-
provisioning, i.e. signaling only at the time of recovery; or pre- provisioning, i.e. signaling only at the time of recovery; or pre-
signaling, i.e., signaling prior to recovery. signaling, i.e., signaling prior to recovery.
E. Mannie (Editor) et al. Standard Track 44
In addition, P&R can be applied on a local or end-to-end basis. In In addition, P&R can be applied on a local or end-to-end basis. In
the local approach, P&R is focused on the local proximity of the the local approach, P&R is focused on the local proximity of the
fault in order to reduce delay in restoring service. In the end-to- fault in order to reduce delay in restoring service. In the end-to-
end approach, the LSP originating and terminating nodes control end approach, the LSP originating and terminating nodes control
recovery. recovery.
Using these strategies, the following recovery mechanisms can be Using these strategies, the following recovery mechanisms can be
defined. defined.
E. Mannie (Editor) et al. Standard Track 44
13.6. Recovery mechanisms: Protection schemes 13.6. Recovery mechanisms: Protection schemes
Note that protection schemes are usually defined in technology Note that protection schemes are usually defined in technology
specific ways, but this does not preclude other solutions. specific ways, but this does not preclude other solutions.
- 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 (see also [GMPLS-FUNCT]). choose the best source (see also [GMPLS-FUNCT]).
skipping to change at line 2472 skipping to change at line 2481
- End-to-end LSP restoration with re-provisioning: an end-to-end - End-to-end LSP restoration with re-provisioning: an end-to-end
restoration path is established after failure. The restoration restoration path is established after failure. The restoration
path may be dynamically calculated after failure, or pre- path may be dynamically calculated after failure, or pre-
calculated before failure (often during LSP establishment). calculated before failure (often during LSP establishment).
Importantly, no signaling is used along the restoration path Importantly, no signaling is used along the restoration path
before failure, and no restoration bandwidth is reserved. before failure, and no restoration bandwidth is reserved.
Consequently, there is no guarantee that a given restoration path Consequently, there is no guarantee that a given restoration path
is available when a failure occurs. Thus, one may have to is available when a failure occurs. Thus, one may have to
crankback to search for an available path. crankback to search for an available path.
E. Mannie (Editor) et al. Standard Track 45
- End-to-end LSP restoration with pre-signaled recovery bandwidth - End-to-end LSP restoration with pre-signaled recovery bandwidth
reservation and no label pre-selection: an end-to-end restoration reservation and no label pre-selection: an end-to-end restoration
path is pre-calculated before failure and a signaling message is path is pre-calculated before failure and a signaling message is
sent along this pre-selected path to reserve bandwidth, but labels sent along this pre-selected path to reserve bandwidth, but labels
are not selected (see also [GMPLS-FUNCT]). are not selected (see also [GMPLS-FUNCT]).
The resources reserved on each link of a restoration path may be The resources reserved on each link of a restoration path may be
shared across different working LSPs that are not expected to fail shared across different working LSPs that are not expected to fail
simultaneously. Local node policies can be applied to define the simultaneously. Local node policies can be applied to define the
degree to which capacity is shared across independent failures. degree to which capacity is shared across independent failures.
E. Mannie (Editor) et al. Standard Track 45
Upon failure detection, LSP signaling is initiated along the Upon failure detection, LSP signaling is initiated along the
restoration path to select labels, and to initiate the appropriate restoration path to select labels, and to initiate the appropriate
cross-connections. cross-connections.
- 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 (see also [GMPLS-FUNCT]). reserved and labels are selected (see also [GMPLS-FUNCT]).
skipping to change at line 2528 skipping to change at line 2537
paths. The risk of simultaneous failure of the two paths can be paths. The risk of simultaneous failure of the two paths can be
reduced by recalculating the restoration path whenever a failure reduced by recalculating the restoration path whenever a failure
occurs along it. occurs along it.
The pre-selection of a label gives less flexibility for multiple The pre-selection of a label gives less flexibility for multiple
failure scenarios than no label pre-selection. If failures occur failure scenarios than no label pre-selection. If failures occur
that affect two LSPs that are sharing a label at a common node that affect two LSPs that are sharing a label at a common node
along their restoration routes, then only one of these LSPs can be along their restoration routes, then only one of these LSPs can be
recovered, unless the label assignment is changed. recovered, unless the label assignment is changed.
E. Mannie (Editor) et al. Standard Track 46
The robustness of a restoration scheme is also determined by the The robustness of a restoration scheme is also determined by the
amount of reserved restoration bandwidth - as the amount of amount of reserved restoration bandwidth - as the amount of
restoration bandwidth sharing increases (reserved bandwidth restoration bandwidth sharing increases (reserved bandwidth
decreases), the restoration scheme becomes less robust to decreases), the restoration scheme becomes less robust to
failures. Restoration schemes with pre-signaled bandwidth failures. Restoration schemes with pre-signaled bandwidth
reservation (with or without label pre-selection) can reserve reservation (with or without label pre-selection) can reserve
adequate bandwidth to ensure recovery from any specific set of adequate bandwidth to ensure recovery from any specific set of
failure events, such as any single SRLG failure, any two SRLG failure events, such as any single SRLG failure, any two SRLG
failures etc. Clearly, more restoration capacity is allocated if a failures etc. Clearly, more restoration capacity is allocated if a
greater degree of failure recovery is required. Thus, the degree greater degree of failure recovery is required. Thus, the degree
E. Mannie (Editor) et al. Standard Track 46
to which the network is protected is determined by the policy that to which the network is protected is determined by the policy that
defines the amount of reserved restoration bandwidth. defines the amount of reserved restoration bandwidth.
- Recovery time: In general, the more pre-planning of the - Recovery time: In general, the more pre-planning of the
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-
skipping to change at line 2580 skipping to change at line 2588
the restoration pool. In restoration schemes with re-provisioning, the restoration pool. In restoration schemes with re-provisioning,
a pool of restoration capacity can be defined from which all a pool of restoration capacity can be defined from which all
restoration routes are selected after failure. Thus, the degree of restoration routes are selected after failure. Thus, the degree of
sharing is defined by the amount of available restoration sharing is defined by the amount of available restoration
capacity. In restoration with pre-signaled bandwidth reservation, capacity. In restoration with pre-signaled bandwidth reservation,
the amount of reserved restoration capacity is determined by the the amount of reserved restoration capacity is determined by the
local bandwidth reservation policies. In all restoration schemes, local bandwidth reservation policies. In all restoration schemes,
pre-emptable resources can use spare restoration capacity when pre-emptable resources can use spare restoration capacity when
that capacity is not being used for failure recovery. that capacity is not being used for failure recovery.
E. Mannie (Editor) et al. Standard Track 47
14. Network Management 14. Network Management
Service Providers (SPs) use network management extensively to Service Providers (SPs) use network management extensively to
configure, monitor or provision various devices in their network. It configure, monitor or provision various devices in their network. It
is important to note that a SP's equipment may be distributed across is important to note that a SP's equipment may be distributed across
geographically separate sites thus making distributed management geographically separate sites thus making distributed management
even more important. The service provider should utilize an NMS even more important. The service provider should utilize an NMS
system and standard management protocols such as SNMP (see system and standard management protocols such as SNMP (see
[RFC3410], [RFC3411] and [RFC3416]) and the relevant MIB modules as [RFC3410], [RFC3411] and [RFC3416]) and the relevant MIB modules as
standard interfaces to configure, monitor and provision devices at standard interfaces to configure, monitor and provision devices at
various locations. The service provider may also wish to use the various locations. The service provider may also wish to use the
command line interface (CLI) provided by vendors with their devices. command line interface (CLI) provided by vendors with their devices.
However, this is not a standard or recommended solution because However, this is not a standard or recommended solution because
there is no standard CLI language or interface, which results in N there is no standard CLI language or interface, which results in N
E. Mannie (Editor) et al. Standard Track 47
different CLIs in a network with devices from N different vendors. different CLIs in a network with devices from N different vendors.
In the context of GMPLS, it is extremely important for standard In the context of GMPLS, it is extremely important for standard
interfaces to the SP's devices (e.g. SNMP) to exist due to the interfaces to the SP's devices (e.g. SNMP) to exist due to the
nature of the technology itself. Since GMPLS comprises many nature of the technology itself. Since GMPLS comprises many
different layers of control-plane and data-plane technology, it is different layers of control-plane and data-plane technology, it is
important for management interfaces in this area to be flexible important for management interfaces in this area to be flexible
enough to allow the manager to manage GMPLS easily, and in a enough to allow the manager to manage GMPLS easily, and in a
standard way. standard way.
14.1. Network Management Systems (NMS) 14.1. Network Management Systems (NMS)
skipping to change at line 2636 skipping to change at line 2644
ubiquitously to provision, configure and monitor devices in non- ubiquitously to provision, configure and monitor devices in non-
heterogeneous networks or across SP's network boundaries. heterogeneous networks or across SP's network boundaries.
14.2. Management Information Base (MIB) 14.2. Management Information Base (MIB)
In the context of GMPLS, it is extremely important for standard In the context of GMPLS, it is extremely important for standard
interfaces to devices to exist due to the nature of the technology interfaces to devices to exist due to the nature of the technology
itself. Since GMPLS comprises many different layers of control-plane itself. Since GMPLS comprises many different layers of control-plane
technology, it is important for SNMP MIB modules in this area to be technology, it is important for SNMP MIB modules in this area to be
flexible enough to allow the manager to manage the entire control flexible enough to allow the manager to manage the entire control
E. Mannie (Editor) et al. Standard Track 48
plane. This should be done using MIB modules that may cooperate plane. This should be done using MIB modules that may cooperate
(i.e. coordinated row-creation on the agent) or through more (i.e. coordinated row-creation on the agent) or through more
generalized MIB modules that aggregate some of the desired actions generalized MIB modules that aggregate some of the desired actions
to be taken and push those details down to the devices. It is to be taken and push those details down to the devices. It is
important to note that in certain circumstances, it may be necessary important to note that in certain circumstances, it may be necessary
to duplicate some small subset of manageable objects in new MIB to duplicate some small subset of manageable objects in new MIB
modules for management convenience. Control of some parts of GMPLS modules for management convenience. Control of some parts of GMPLS
may also be achieved using existing MIB interfaces (i.e. existing may also be achieved using existing MIB interfaces (i.e. existing
SONET MIB) or using separate ones, which are yet to be defined. MIB SONET MIB) or using separate ones, which are yet to be defined. MIB
modules may have been previously defined in the IETF or ITU. Current modules may have been previously defined in the IETF or ITU. Current
MIB modules may need to be extended to facilitate some of the new MIB modules may need to be extended to facilitate some of the new
functionality desired by GMPLS. In these cases, the working group functionality desired by GMPLS. In these cases, the working group
should work on new versions of these MIB modules so that these should work on new versions of these MIB modules so that these
extensions can be added. extensions can be added.
E. Mannie (Editor) et al. Standard Track 48
14.3. Tools 14.3. Tools
As in traditional networks, standard tools such as traceroute As in traditional networks, standard tools such as traceroute
[RFC1393] and ping [RFC2151] are needed for debugging and [RFC1393] and ping [RFC2151] are needed for debugging and
performance monitoring of GMPLS networks, and mainly for the control performance monitoring of GMPLS networks, and mainly for the control
plane topology, that will mimic the data plane topology. plane topology, that will mimic the data plane topology.
Furthermore, such tools provide network reachability information. Furthermore, such tools provide network reachability information.
The GMPLS control protocols will need to expose certain pieces of The GMPLS control protocols will need to expose certain pieces of
information in order for these tools to function properly and to information in order for these tools to function properly and to
provide information germane to GMPLS. These tools should be made provide information germane to GMPLS. These tools should be made
skipping to change at line 2692 skipping to change at line 2700
That is, if 1000 interfaces at layer B are stacked above a single That is, if 1000 interfaces at layer B are stacked above a single
interface below it at layer A, and the interface at A goes down, the interface below it at layer A, and the interface at A goes down, the
interfaces at layer B should not emit notifications. Instead, the interfaces at layer B should not emit notifications. Instead, the
interface at layer A should emit a single notification. The NMS interface at layer A should emit a single notification. The NMS
receiving this notification should be able to correlate the fact receiving this notification should be able to correlate the fact
that this interface has many others stacked above it and take that this interface has many others stacked above it and take
appropriate action, if necessary. appropriate action, if necessary.
Devices that support GMPLS should provide mechanisms for Devices that support GMPLS should provide mechanisms for
aggregating, summarizing, enabling and disabling of inter-layer aggregating, summarizing, enabling and disabling of inter-layer
E. Mannie (Editor) et al. Standard Track 49
notifications for the reasons described above. In the context of notifications for the reasons described above. In the context of
SNMP MIB modules, all MIB modules that are used by GMPLS must SNMP MIB modules, all MIB modules that are used by GMPLS must
provide enable/disable objects for all notification objects. provide enable/disable objects for all notification objects.
Furthermore, these MIBs must also provide notification summarization Furthermore, these MIBs must also provide notification summarization
objects or functionality (as described above) as well. NMS systems objects or functionality (as described above) as well. NMS systems
and standard tools which process notifications or keep track of the and standard tools which process notifications or keep track of the
many layers on any given devices must be capable of processing the many layers on any given devices must be capable of processing the
vast amount of information which may potentially be emitted by vast amount of information which may potentially be emitted by
network devices running GMPLS at any point in time. network devices running GMPLS at any point in time.
15. Security Considerations 15. Security Considerations
GMPLS defines a control plane architecture for multiple types of GMPLS defines a control plane architecture for multiple technologies
network elements. In general, since LSPs established using GMPLS are and types of network elements. In general, since LSPs established
using GMPLS may carry high volumes of data and consume significant
E. Mannie (Editor) et al. Standard Track 49
expected to carry high volumes of data and consume significant
network resources, security mechanisms are required to safeguard the network resources, security mechanisms are required to safeguard the
underlying network against attacks on the control plane and/or underlying network against attacks on the control plane and/or
unauthorized usage of data transport resources. unauthorized usage of data transport resources. The GMPLS control
plane should therefore include mechanisms that prevent or minimize
the risk of attackers being able to inject and/or snoop on control
traffic. These risks depend on the level of trust between nodes that
exchange GMPLS control messages, as well as the realization and
physical characteristics of the control channel. For example, an in-
band, in-fiber control channel over SONET/SDH overhead bytes is, in
general, considered less vulnerable than a control channel realized
over an out-of-band IP network.
Security requirements depend on the level of trust between nodes Security mechanisms can provide authentication and confidentiality.
that exchange GMPLS control messages as well as the exposure of the Authentication can provide origin verification, message integrity
control channel to third parties. In general, a network node may and replay protection, while confidentiality ensures that a third
apply more relaxed security requirements when exchanging GMPLS party cannot decipher the contents of a message. In situations where
control messages with nodes under the same administrative domain GMPLS deployment requires primarily authentication, the respective
than when talking to nodes in a different domain. In this respect, authentication mechanisms of the GMPLS component protocols may be
network to user (UNI) and network-to-network interfaces are expected used (see [RFC2747], [RFC3036], [RFC2385] and [LMP]). Additionally,
to have higher security requirements than node-to-node interfaces. the IPsec suite of protocols (see [RFC2402], [RFC2406] and
[RFC2409]) may be used to provide authentication, confidentiality or
both, for a GMPLS control channel. IPsec thus offers the benefits of
combined protection for all GMPLS component protocols as well as key
management.
Security mechanisms can provide two main properties: authentication A related issue is that of the authorization of requests for
and confidentiality. Authentication can provide origin verification, resources by GMPLS-capable nodes. Authorization determines whether a
message integrity and replay protection, while confidentiality given party, presumable already authenticated, has a right to access
ensures that a third party cannot decipher the contents of a the requested resources. This determination is typically a matter of
message. In situations where GMPLS deployment requires primarily local policy control [RFC2753], for example by setting limits on the
authentication, the respective authentication mechanisms of the total bandwidth available to some party in the presence of resource
GMPLS component protocols may be used (see [RFC2747], [RFC3036], contention. Such policies may become quite complex as the number of
[RFC2385] and [LMP]). Additionally, the IPSEC suite of protocols users, types of resources and sophistication of authorization rules
(see [RFC2402], [RFC2406] and [RFC2409]) may be used to provide increases.
authentication, confidentiality or both, for a GMPLS control
channel; this option offers the benefit of combined protection of
all GMPLS component protocols.
Note however that GMPLS itself introduces no new security After authenticating requests, control elements should match them
considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP), against the local authorization policy. These control elements must
routing protocols (OSPF-TE, IS-IS-TE) or network management be capable of making decisions based on the identity of the
requester, as verified cryptographically and/or topologically. For
E. Mannie (Editor) et al. Standard Track 50
example, decisions may depend on whether the interface through which
the request is made is an inter- or intra-domain one. The use of
appropriate local authorization policies may help in limiting the
impact of security breaches in remote parts of a network.
Finally, it should be noted that GMPLS itself introduces no new
security considerations to the current MPLS-TE signaling (RSVP-TE,
CR-LDP), 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.
Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH
discussions we had together. Thanks also to Pedro Falcao, Alexandre discussions we had together. Thanks also to Pedro Falcao, Alexandre
Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from
skipping to change at line 2762 skipping to change at line 2790
17. Intellectual Property Considerations 17. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC2026]. This section is taken from Section 10.4 of [RFC2026].
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
E. Mannie (Editor) et al. Standard Track 50
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
skipping to change at line 2787 skipping to change at line 2813
Director. Director.
18. References 18. References
18.1 Normative References 18.1 Normative References
[ANSI-T1.105] "Synchronous Optical Network (SONET): Basic [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, Description Including Multiplex Structure, Rates,
And Formats," ANSI T1.105, 2000. And Formats," ANSI T1.105, 2000.
E. Mannie (Editor) et al. Standard Track 51
[BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
in MPLS Traffic Engineering," Work in Progress. in MPLS Traffic Engineering," Work in Progress.
[CR-LDP] B.Jamoussi (Editor) et al., "Constraint-Based LSP [CR-LDP] B.Jamoussi (Editor) et al., "Constraint-Based LSP
Setup using LDP," IETF RFC 3212, January 2002. Setup using LDP," IETF RFC 3212, January 2002.
[CR-LDP-GMPLS] P.Ashwood-Smith and L.Berger (Editors) et al., [CR-LDP-GMPLS] P.Ashwood-Smith and L.Berger (Editors) et al.,
"Generalized MPLS Signaling - CR-LDP Extensions," "Generalized MPLS Signaling - CR-LDP Extensions,"
IETF RFC 3472, January 2003. IETF RFC 3472, January 2003.
skipping to change at line 2819 skipping to change at line 2846
Overlay Model," Work in Progress. Overlay Model," Work in Progress.
[GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
Extensions in Support of Generalized MPLS," Work in Extensions in Support of Generalized MPLS," Work in
Progress. Progress.
[GMPLS-SIG] L.Berger (Editor) et al., "Generalized MPLS - [GMPLS-SIG] L.Berger (Editor) et al., "Generalized MPLS -
Signaling Functional Description," IETF RFC 3471, Signaling Functional Description," IETF RFC 3471,
January 2003. January 2003.
E. Mannie (Editor) et al. Standard Track 51
[GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
"Generalized MPLS Extensions for SONET and SDH "Generalized MPLS Extensions for SONET and SDH
Control," Work in progress. Control," Work in progress.
[HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with [HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with
Generalized MPLS TE," Work in Progress. Generalized MPLS TE," Work in Progress.
[ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network [ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841, Protection Architectures," Recommendation G.841,
October 1998. October 1998.
skipping to change at line 2842 skipping to change at line 2868
Label Distribution Protocol (LDP)," IETF RFC 3479, Label Distribution Protocol (LDP)," IETF RFC 3479,
February 2003. February 2003.
[LMP] J.P.Lang (Editor) et al., "Link Management Protocol [LMP] J.P.Lang (Editor) et al., "Link Management Protocol
(LMP)," Work in progress. (LMP)," Work in progress.
[LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for [LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for
WDM Optical Line Systems (LMP-WDM)," Work in WDM Optical Line Systems (LMP-WDM)," Work in
progress. progress.
E. Mannie (Editor) et al. Standard Track 52
[OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions
in Support of Generalized MPLS," Work in Progress. in Support of Generalized MPLS," Work in Progress.
[OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic [OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic
Engineering Extensions to OSPF", Work in Progress. Engineering Extensions to OSPF", Work in Progress.
[RFC1393] G.Malkin, "Traceroute Using an IP Option", IETF RFC [RFC1393] G.Malkin, "Traceroute Using an IP Option", IETF RFC
1393, January 1993. 1393, January 1993.
[RFC2026] S.Bradner, "The Internet Standards Process -- Revision [RFC2026] S.Bradner, "The Internet Standards Process -- Revision
skipping to change at line 2872 skipping to change at line 2899
[RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," IETF [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," IETF
RFC 2402, November 1998. 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, November 1998. 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, November 1998. (IKE)", IETF RFC 2409, November 1998.
E. Mannie (Editor) et al. Standard Track 52
[RFC2747] F.Baker et al., "RSVP Cryptographic Authentication," [RFC2747] F.Baker et al., "RSVP Cryptographic Authentication,"
IETF RFC 2747, January 2000. IETF RFC 2747, January 2000.
[RFC2753] R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework for
Policy-based Admission Control," IETF RFC 2753, 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, and R.Callon, "Multiprotocol [RFC3031] E.Rosen, A.Viswanathan, and R.Callon, "Multiprotocol
Label Switching Architecture," IETF RFC 3031, January Label Switching Architecture," IETF RFC 3031, January
2001. 2001.
[RFC3036] L.Andersson, P.Doolan, N.Feldman, A.Fredette, and [RFC3036] L.Andersson, P.Doolan, N.Feldman, A.Fredette, and
B.Thomas, "LDP Specification," IETF RFC 3036, January B.Thomas, "LDP Specification," IETF RFC 3036, January
2001. 2001.
[RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An Architecture [RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An Architecture
for Describing Simple Network Management Protocol for Describing Simple Network Management Protocol
(SNMP) Management Frameworks," IETF RFC 3411, December (SNMP) Management Frameworks," IETF RFC 3411, December
2002. 2002.
E. Mannie (Editor) et al. Standard Track 53
[RFC3414] U.Blumenthal and B.Wijnen, "User-based Security Model [RFC3414] U.Blumenthal and B.Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)," IETF RFC 3414, December 2002. Protocol (SNMPv3)," IETF RFC 3414, December 2002.
[RFC3415] B.Wijnen, R.Presuhn, and K.McCloghrie, "View-based [RFC3415] B.Wijnen, R.Presuhn, and K.McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)," IETF RFC 3415, December Management Protocol (SNMP)," IETF RFC 3415, December
2002. 2002.
[RFC3416] R.Presuhn (Editor), "Version 2 of the Protocol [RFC3416] R.Presuhn (Editor), "Version 2 of the Protocol
skipping to change at line 2927 skipping to change at line 2958
[RSVP-TE-UNNUM] K.Kompella and Y.Rekhter, "Signalling Unnumbered [RSVP-TE-UNNUM] K.Kompella and Y.Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)," IETF RFC 3477, January 2003. Engineering (RSVP-TE)," IETF RFC 3477, January 2003.
18.2 Informative References 18.2 Informative References
[ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic [ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic
Engineering," Work in Progress. Engineering," Work in Progress.
[ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS
E. Mannie (Editor) et al. Standard Track 53
Extensions in Support of Generalized MPLS," Work in Extensions in Support of Generalized MPLS," Work in
Progress. Progress.
[MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution [MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution
of Transport Network Survivability," IEEE of Transport Network Survivability," IEEE
Communications, August 1999. Communications, August 1999.
[OLI-REQ] A.Fredette (Editor), "Optical Link Interface [OLI-REQ] A.Fredette (Editor), "Optical Link Interface
Requirements," Work in Progress. Requirements," Work in Progress.
[RFC3386] W.Lai, D.McDysan, J.Boyle, et al., "Network Hierarchy [RFC3386] W.Lai, D.McDysan, et al., "Network Hierarchy and Multi-
and Multi-layer Survivability," IETF RFC 3386, November layer Survivability," IETF RFC 3386, November 2002.
2002.
[RFC3410] J.Case, R.Mundy, D.Partain, and B. Stewart, [RFC3410] J.Case, R.Mundy, D.Partain, and B. Stewart,
"Introduction and Applicability Statements for "Introduction and Applicability Statements for
Internet-Standard Management Framework," IETF RFC 3410, Internet-Standard Management Framework," IETF RFC 3410,
December 2002. December 2002.
E. Mannie (Editor) et al. Standard Track 54
[RFC3469] V.Sharma and F.Hellstrand (Editors), "Framework for [RFC3469] V.Sharma and F.Hellstrand (Editors), "Framework for
Multi-Protocol Label Switching (MPLS)-based Recovery," Multi-Protocol Label Switching (MPLS)-based Recovery,"
IETF RFC 3469, February 2003. IETF RFC 3469, February 2003.
[SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma, [SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma,
"Framework for GMPLS-based Control of SDH/SONET "Framework for GMPLS-based Control of SDH/SONET
Networks," Work in Progress. Networks," Work in Progress.
19. Author's Address 19. Author's Address
skipping to change at line 2980 skipping to change at line 3009
Daniel O. Awduche (Consult) Thomas D. Nadeau (Cisco) Daniel O. Awduche (Consult) Thomas D. Nadeau (Cisco)
Email: awduche@awduche.com 250 Apollo Drive Email: awduche@awduche.com 250 Apollo Drive
Chelmsford, MA 01824, USA Chelmsford, MA 01824, USA
Email: tnadeau@cisco.com Email: tnadeau@cisco.com
Ayan Banerjee (Calient) Lyndon Ong (Ciena) Ayan Banerjee (Calient) Lyndon Ong (Ciena)
5853 Rue Ferrari 10480 Ridgeview Ct 5853 Rue Ferrari 10480 Ridgeview Ct
San Jose, CA 95138, USA Cupertino, CA 95014, USA San Jose, CA 95138, USA Cupertino, CA 95014, USA
Email: abanerjee@calient.net Email: lyong@ciena.com Email: abanerjee@calient.net Email: lyong@ciena.com
E. Mannie (Editor) et al. Standard Track 54
Debashis Basak (Accelight) Dimitri Papadimitriou (Alcatel) Debashis Basak (Accelight) Dimitri Papadimitriou (Alcatel)
70 Abele Road, Bldg.1200 Francis Wellesplein, 1 70 Abele Road, Bldg.1200 Francis Wellesplein, 1
Bridgeville, PA 15017, USA B-2018 Antwerpen, Belgium Bridgeville, PA 15017, USA B-2018 Antwerpen, Belgium
Email: dbasak@accelight.com Email: Email: dbasak@accelight.com Email:
dimitri.papadimitriou@alcatel.be dimitri.papadimitriou@alcatel.be
Lou Berger (Movaz) Dimitrios Pendarakis (Tellium) Lou Berger (Movaz) Dimitrios Pendarakis (Tellium)
7926 Jones Branch Drive 2 Crescent Place, P.O. Box 901 7926 Jones Branch Drive 2 Crescent Place, P.O. Box 901
MCLean VA, 22102, USA Oceanport, NJ 07757-0901, USA MCLean VA, 22102, USA Oceanport, NJ 07757-0901, USA
Email: lberger@movaz.com Email: dpendarakis@tellium.com Email: lberger@movaz.com Email: dpendarakis@tellium.com
Greg Bernstein Bala Rajagopalan (Tellium) Greg Bernstein (Grotto) Bala Rajagopalan (Tellium)
(Grotto Networking) 2 Crescent Place, P.O. Box 901 Email: 2 Crescent Place, P.O. Box 901
Email: Oceanport, NJ 07757-0901, USA gregb@grotto-networking.com Oceanport, NJ 07757-0901, USA
gregb@grotto-networking.com Email: braja@tellium.com Email: braja@tellium.com
Sudheer Dharanikota (Consult) Yakov Rekhter (Juniper) Sudheer Dharanikota (Consult) Yakov Rekhter (Juniper)
Email: sudheer@ieee.org 1194 N. Mathilda Ave. Email: sudheer@ieee.org 1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA Sunnyvale, CA 94089, USA
Email: yakov@juniper.net Email: yakov@juniper.net
John Drake (Calient) Debanjan Saha E. Mannie (Editor) et al. Standard Track 55
5853 Rue Ferrari IBM Watson Research Center John Drake (Calient) Debanjan Saha (Tellium)
San Jose, CA 95138, USA Email: dsaha@us.ibm.com 5853 Rue Ferrari 2 Crescent Place
Email: jdrake@calient.net San Jose, CA 95138, USA Oceanport, NJ 07757-0901, USA
Email: jdrake@calient.net Email: dsaha@tellium.com
Yanhe Fan (Axiowave) Hal Sandick Yanhe Fan (Axiowave) Hal Sandick
200 Nickerson Road Shepard M.S. 200 Nickerson Road Shepard M.S.
Marlborough, MA 01752, USA 2401 Dakota Street Marlborough, MA 01752, USA 2401 Dakota Street
Email: yfan@axiowave.com Durham, NC 27705, USA Email: yfan@axiowave.com Durham, NC 27705, USA
Email: sandick@nc.rr.com Email: sandick@nc.rr.com
Don Fedyk (Nortel) Vishal Sharma (Metanoia) Don Fedyk (Nortel) Vishal Sharma (Metanoia)
600 Technology Park Drive 1600 Villa Street, Unit 352 600 Technology Park Drive 1600 Villa Street, Unit 352
Billerica, MA 01821, USA Mountain View, CA 94041, USA Billerica, MA 01821, USA Mountain View, CA 94041, USA
skipping to change at line 3034 skipping to change at line 3063
Dan Guo (Turin) Z. Bo Tang (Tellium) Dan Guo (Turin) Z. Bo Tang (Tellium)
1415 N. McDowell Blvd, Petaluma, 2 Crescent Place, P.O. Box 901 1415 N. McDowell Blvd, Petaluma, 2 Crescent Place, P.O. Box 901
CA 95454, USA Oceanport, NJ 07757-0901, USA CA 95454, USA Oceanport, NJ 07757-0901, USA
Email: dguo@turinnetworks.com Email: btang@tellium.com Email: dguo@turinnetworks.com Email: btang@tellium.com
Kireeti Kompella (Juniper) Jennifer Yates (AT&T) Kireeti Kompella (Juniper) Jennifer Yates (AT&T)
1194 N. Mathilda Ave. 180 Park Avenue 1194 N. Mathilda Ave. 180 Park Avenue
Sunnyvale, CA 94089, USA Florham Park, NJ 07932, USA Sunnyvale, CA 94089, USA Florham Park, NJ 07932, USA
Email: kireeti@juniper.net Email: jyates@research.att.com Email: kireeti@juniper.net Email: jyates@research.att.com
E. Mannie (Editor) et al. Standard Track 55
Alan Kullberg (NetPlane) George R. Young (Edgeflow) Alan Kullberg (NetPlane) George R. Young (Edgeflow)
888 Washington 329 March Road 888 Washington 329 March Road
St.Dedham, MA 02026, USA Ottawa, Ontario, K2K 2E1, Canada St.Dedham, MA 02026, USA Ottawa, Ontario, K2K 2E1, Canada
Email: akullber@netplane.com Email: george.young@edgeflow.com Email: akullber@netplane.com Email: george.young@edgeflow.com
Jonathan P. Lang John Yu (Hammerhead Systems) Jonathan P. Lang John Yu (Hammerhead Systems)
(Rincon Networks) 640 Clyde Court (Rincon Networks) 640 Clyde Court
Email: jplang@ieee.org Mountain View, CA 94043, USA Email: jplang@ieee.org Mountain View, CA 94043, USA
Email: john@hammerheadsystems.com Email: john@hammerheadsystems.com
 End of changes. 

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