draft-ietf-mpls-generalized-cr-ldp-07.txt   rfc3472.txt 
Network Working Group
Internet Draft Peter Ashwood-Smith - Editor (Nortel Networks)
Expiration Date: February 2003 Lou Berger - Editor (Movaz Networks)
August 2002 Network Working Group P. Ashwood-Smith, Editor
Request for Comments: 3472 Nortel Networks
Generalized MPLS Signaling - CR-LDP Extensions Category: Standards Track L. Berger, Editor
Movaz Networks
January 2003
draft-ietf-mpls-generalized-cr-ldp-07.txt Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, improvements. Please refer to the current edition of the "Internet
and its working groups. Note that other groups may also distribute Official Protocol Standards" (STD 1) for the standardization state
working documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (2003). All Rights Reserved.
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to MPLS (Multi-Protocol Label This document describes extensions to Multi-Protocol Label Switching
Switching) CR-LDP (Constraint-based Routed Label Distribution (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP)
Protocol) signaling required to support Generalized MPLS. Generalized signaling required to support Generalized MPLS. Generalized MPLS
MPLS extends the MPLS control plane to encompass time-division (e.g., extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy, Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g. SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber). This document incoming port or fiber to outgoing port or fiber). This document
presents a CR-LDP specific description of the extensions. A generic presents a CR-LDP specific description of the extensions. A generic
functional description can be found in separate documents. functional description can be found in separate documents.
Contents Table of Contents
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request ............................... 3
2.2 Generalized Label ....................................... 4
2.3 Waveband Switching ...................................... 5
2.4 Suggested Label ......................................... 6
2.5 Label Set ............................................... 6
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 8
4. Notification on Label Error ............................... 9
5. Explicit Label Control .................................. 9
5.1 Procedures .............................................. 9
6. Protection TLV ............................................ 10
6.1 Procedures .............................................. 11
7. Administrative Status Information ......................... 11
7.1 Admin Status TLV ........................................ 11
7.2 REQUEST and MAPPING Message Procedures .................. 12
7.3 Notification Message Procedures ......................... 13
8. Control Channel Separation ................................ 14
8.1 Interface Identification ................................ 14
8.2 Errored Interface Identification ........................ 15
9. Fault Handling ......................................... 17
10 Acknowledgments ........................................... 17
11. Security Considerations ................................... 17
12. IANA Considerations ....................................... 17
13. Intellectual Property Considerations ...................... 18
14. References ................................................ 18
14.1 Normative References ................................... 18
14.2 Informative References ................................. 19
15. Contributors .............................................. 19
16. Editors' Addresses ........................................ 22
17. Full Copyright Statement ................................... 23
1 Introduction ................................................ 3
2 Label Related Formats ...................................... 3
2.1 Generalized Label Request ................................... 3
2.2 Generalized Label ........................................... 5
2.3 Waveband Switching .......................................... 6
2.4 Suggested Label ............................................. 7
2.5 Label Set ................................................... 7
3 Bidirectional LSPs .......................................... 9
3.1 Procedures .................................................. 9
4 Notification on Label Error ................................. 9
5 Explicit Label Control ...................................... 10
5.1 Procedures .................................................. 10
6 Protection TLV .............................................. 11
6.1 Procedures .................................................. 12
7 Administrative Status Information ........................... 12
7.1 Admin Status TLV ............................................ 12
7.2 REQUEST and MAPPING Message Procedures ...................... 13
7.3 Notification Message Procedures ............................. 14
8 Control Channel Separation .................................. 15
8.1 Interface Identification .................................... 15
8.2 Errored Interface Identification ............................ 17
9 Fault Handling ........................................... 18
10 Acknowledgments ............................................. 19
11 Security Considerations ..................................... 19
12 IANA Considerations ......................................... 19
13 Intellectual Property Considerations ........................ 20
14 References .................................................. 20
14.1 Normative References ........................................ 20
14.2 Informative References ...................................... 21
15 Contributors ................................................ 21
16 Contact Addresses ........................................... 24
1. Introduction 1. Introduction
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
and switching to include support of three new classes of interfaces and switching to include support of three new classes of interfaces
and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
Fiber-Switch (FSC). A functional description of the extensions to Fiber-Switch (FSC). A functional description of the extensions to
MPLS signaling needed to support the new classes of interfaces and MPLS signaling needed to support the new classes of interfaces and
switching is provided in [GMPLS-SIG]. This document presents CR-LDP switching is provided in [RFC3471]. This document presents CR-LDP
specific formats and mechanisms needed to support all four classes of specific formats and mechanisms needed to support all four classes of
interfaces. RSVP-TE extensions can be found in [GMPLS-RSVP]. interfaces. RSVP-TE extensions can be found in [RFC3473].
[GMPLS-SIG] should be viewed as a companion document to this [RFC3471] should be viewed as a companion document to this document.
document. The format of this document parallels [GMPLS-SIG]. It The format of this document parallels [RFC3471]. It should be noted
should be noted that the RSVP-TE specific version of Generalized MPLS that the RSVP-TE specific version of Generalized MPLS includes RSVP
includes RSVP specific support for rapid failure notification, see specific support for rapid failure notification, see Section 4
Section 4 [GMPLS-RSVP]. For CR-LDP there is not currently a similar [RFC3473]. For CR-LDP there is not currently a similar mechanism.
mechanism. When a failure is detected it will be propagated with When a failure is detected it will be propagated with
RELEASE/WITHDRAW messages radially outward from the point of failure. RELEASE/WITHDRAW messages radially outward from the point of failure.
Resources are to be released in this phase and actual resource Resources are to be released in this phase and actual resource
information may be fed back to the source using a feedback information may be fed back to the source using a feedback
mechanisms. mechanisms.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Label Related Formats 2. Label Related Formats
This section defines formats for a generalized label request, a This section defines formats for a generalized label request, a
generalized label, support for waveband switching, suggested label generalized label, support for waveband switching, suggested label
and label sets. and label sets.
2.1. Generalized Label Request 2.1. Generalized Label Request
A REQUEST message SHOULD contain as specific an LSP (Label Switched A REQUEST message SHOULD contain as specific an LSP (Label Switched
Path) Encoding Type as possible to allow the maximum flexibility in Path) Encoding Type as possible to allow the maximum flexibility in
switching by transit LSRs. A Generalized Label Request TLV is set by switching by transit LSRs. A Generalized Label Request Type, Length,
the ingress node, transparently passed by transit nodes, and used by and Value (TLV) is set by the ingress node, transparently passed by
the egress node. The Switching Type field may also be updated hop- transit nodes, and used by the egress node. The Switching Type field
by-hop. may also be updated hop-by-hop.
The format of a Generalized Label Request is: The format of a Generalized Label Request is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x0824) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID | | LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [RFC3471] for a description of parameters.
2.1.1. Procedures 2.1.1. Procedures
A node processing a REQUEST message containing a Generalized Label A node processing a REQUEST message containing a Generalized Label
Request must verify that the requested parameters can be satisfied by Request must verify that the requested parameters can be satisfied by
the incoming interface, the node and by the outgoing interface. The the incoming interface, the node and by the outgoing interface. The
node may either directly support the LSP or it may use a tunnel (FA), node may either directly support the LSP or it may use a tunnel (FA),
i.e., another class of switching. In either case, each parameter i.e., another class of switching. In either case, each parameter
must be checked. must be checked.
Note that local node policy dictates when tunnels may be used and Note that local node policy dictates when tunnels may be used and
when they may be created. Local policy may allow for tunnels to be when they may be created. Local policy may allow for tunnels to be
dynamically established or may be solely administratively controlled. dynamically established or may be solely administratively controlled.
For more information on tunnels and processing of ER hops when using For more information on tunnels and processing of ER (Explicit Route)
tunnels see [MPLS-HIERARCHY]. hops when using tunnels see [MPLS-HIERARCHY].
Transit and egress nodes MUST verify that the node itself and, where Transit and egress nodes MUST verify that the node itself and, where
appropriate, that the outgoing interface or tunnel can support the appropriate, that the outgoing interface or tunnel can support the
requested LSP Encoding Type. If encoding cannot be supported, the requested LSP Encoding Type. If encoding cannot be supported, the
node MUST generate a NOTIFICATION message, with a "Routing node MUST generate a NOTIFICATION message, with a "Routing
problem/Unsupported Encoding" indication. problem/Unsupported Encoding" indication.
Nodes MUST verify that the type indicated in the Switching Type Nodes MUST verify that the type indicated in the Switching Type
parameter is supported on the corresponding incoming interface. If parameter is supported on the corresponding incoming interface. If
the type cannot be supported, the node MUST generate a NOTIFICATION the type cannot be supported, the node MUST generate a NOTIFICATION
message with a "Routing problem/Switching Type" indication. message with a "Routing problem/Switching Type" indication.
The G-PID parameter is normally only examined at the egress. If the The G-PID parameter is normally only examined at the egress. If the
indicated G-PID cannot be supported then the egress MUST generate a indicated G-PID cannot be supported then the egress MUST generate a
NOTIFICATION message, with a "Routing problem/Unsupported G-PID" NOTIFICATION message, with a "Routing problem/Unsupported G-PID"
indication. In the case of PSC and when penultimate hop popping indication. In the case of PSC and when penultimate hop popping
(PHP) is requested, the penultimate hop also examines the (stored) G- (PHP) is requested, the penultimate hop also examines the (stored)
PID during the processing of the MAPPING message. In this case if G-PID during the processing of the MAPPING message. In this case if
the G-PID is not supported, then the penultimate hop MUST generate a the G-PID is not supported, then the penultimate hop MUST generate a
NOTIFICATION message with a "Routing problem/Unacceptable label NOTIFICATION message with a "Routing problem/Unacceptable label
value" indication. The generated NOTIFICATION message MAY include an value" indication. The generated NOTIFICATION message MAY include an
Acceptable Label Set, see Section 4. Acceptable Label Set, see Section 4.
When an error message is not generated, normal processing occurs. In When an error message is not generated, normal processing occurs. In
the transit case this will typically result in a REQUEST message the transit case this will typically result in a REQUEST message
being propagated. In the egress case and PHP special case this will being propagated. In the egress case and PHP special case this will
typically result in a MAPPING message being generated. typically result in a MAPPING message being generated.
2.1.2. Bandwidth Encoding 2.1.2. Bandwidth Encoding
Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV.
See [GMPLS-SIG] for a definition of values to be used for specific See [RFC3471] for a definition of values to be used for specific
signal types. These values are set in the Peak and Committed Data signal types. These values are set in the Peak and Committed Data
Rate fields of the Traffic Parameters TLV. Other bandwidth/service Rate fields of the Traffic Parameters TLV. Other bandwidth/service
related parameters in the TLV are ignored and carried transparently. related parameters in the TLV are ignored and carried transparently.
2.2. Generalized Label 2.2. Generalized Label
The format of a Generalized Label is: The format of a Generalized Label is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x0825) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters and encoding of See [RFC3471] for a description of parameters and encoding of labels.
labels.
2.2.1. Procedures 2.2.1. Procedures
The Generalized Label travels in the upstream direction in MAPPING The Generalized Label travels in the upstream direction in MAPPING
messages. messages.
The presence of both a generalized and normal label TLV in a MAPPING The presence of both a generalized and normal label TLV in a MAPPING
message is a protocol error and should treated as a malformed message message is a protocol error and should treated as a malformed message
by the recipient. by the recipient.
The recipient of a MAPPING message containing a Generalized Label The recipient of a MAPPING message containing a Generalized Label
verifies that the values passed are acceptable. If the label is verifies that the values passed are acceptable. If the label is
unacceptable then the recipient MUST generate a NOTIFICATION message unacceptable then the recipient MUST generate a NOTIFICATION message
with a "Routing problem/MPLS label allocation failure" indication. with a "Routing problem/MPLS label allocation failure" indication.
The generated NOTIFICATION message MAY include an Acceptable Label The generated NOTIFICATION message MAY include an Acceptable Label
Set, see Section 4. Set, see Section 4.
2.3. Waveband Switching 2.3. Waveband Switching
Waveband switching uses the same format as the generalized label, see Waveband switching uses the same format as the generalized label, see
section 2.2. The type TBA is assigned for the Waveband Label. section 2.2. The type 0x0828 is assigned for the Waveband Label.
In the context of waveband switching, the generalized label has the In the context of waveband switching, the generalized label has the
following format: following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x0828) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id | | Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label | | Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label | | End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [RFC3471] for a description of parameters.
2.3.1. Procedures 2.3.1. Procedures
The procedures defined in Section 2.2.1 apply to waveband switching. The procedures defined in Section 2.2.1 apply to waveband switching.
This includes generating a NOTIFICATION message with a "Routing This includes generating a NOTIFICATION message with a "Routing
problem/MPLS label allocation failure" indication if any of the label problem/MPLS label allocation failure" indication if any of the label
fields are unrecognized or unacceptable. fields are unrecognized or unacceptable.
Additionally, when a waveband is switched to another waveband, it is Additionally, when a waveband is switched to another waveband, it is
possible that the wavelengths within the waveband will be mirrored possible that the wavelengths within the waveband will be mirrored
about a center frequency. When this type of switching is employed, about a center frequency. When this type of switching is employed,
the start and end label in the waveband label TLV MUST be flipped the start and end label in the waveband label TLV MUST be swapped
before forwarding the label TLV with the new waveband Id. In this before forwarding the label TLV with the new waveband Id. In this
manner an egress/ingress LSR that receives a waveband label which has manner an egress/ingress LSR that receives a waveband label which has
these values inverted, knows that it must also invert its egress these values inverted, knows that it must also invert its egress
association to pick up the proper wavelengths. Without this association to pick up the proper wavelengths. Without this
mechanism and with an odd number of mirrored switching operations, mechanism and with an odd number of mirrored switching operations,
the egress LSRs will not know that an input wavelength of say L1 will the egress LSRs will not know that an input wavelength of say L1 will
emerge from the waveband tunnel as L100. emerge from the waveband tunnel as L100.
This operation MUST be performed in both directions when a This operation MUST be performed in both directions when a
bidirectional waveband tunnel is being established. bidirectional waveband tunnel is being established.
2.4. Suggested Label 2.4. Suggested Label
The format of a suggested label is identical to a generalized label. The format of a suggested label is identical to a generalized label.
It is used in REQUEST messages. Suggested Label uses type = 0x904. It is used in REQUEST messages. Suggested Label uses type = 0x904.
Errors in received Suggested Labels MUST be ignored. This includes Errors in received Suggested Labels MUST be ignored. This includes
any received inconsistent or unacceptable values. any received inconsistent or unacceptable values.
Per [GMPLS-SIG], if a downstream node passes a label value that Per [RFC3471], if a downstream node passes a label value that differs
differs from the suggested label upstream, the upstream LSR MUST from the suggested label upstream, the upstream LSR MUST either
either reconfigure itself so that it uses the label specified by the reconfigure itself so that it uses the label specified by the
downstream node or generate a NOTIFICATION message with a "Routing downstream node or generate a NOTIFICATION message with a "Routing
problem/Unacceptable label value" indication. Furthermore, an problem/Unacceptable label value" indication. Furthermore, an
ingress node SHOULD NOT transmit data traffic using a suggested label ingress node SHOULD NOT transmit data traffic using a suggested label
until the downstream node passes corresponding a label upstream. until the downstream node passes corresponding a label upstream.
2.5. Label Set 2.5. Label Set
The format of a Label Set is: The format of a Label Set is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x0827) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type | | Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 | | Subchannel 1 |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N | | Subchannel N |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Type: 14 bits
Label Type: 14 bits
Indicates the type and format of the labels carried in the TLV. Indicates the type and format of the labels carried in the TLV.
Values match the TLV type of the appropriate Label TLV. Values match the TLV type of the appropriate Label TLV.
See [GMPLS-SIG] for a description of other parameters. See [RFC3471] for a description of other parameters.
2.5.1. Procedures 2.5.1. Procedures
A Label Set is defined via one or more Label Set TLVs. Specific A Label Set is defined via one or more Label Set TLVs. Specific
labels/subchannels can be added to or excluded from a Label Set via labels/subchannels can be added to or excluded from a Label Set via
Action zero (0) and one (1) TLVs respectively. Ranges of Action zero (0) and one (1) TLVs respectively. Ranges of
labels/subchannels can be added to or excluded from a Label Set via labels/subchannels can be added to or excluded from a Label Set via
Action two (2) and three (3) TLVs respectively. When the Label Set Action two (2) and three (3) TLVs respectively. When the Label Set
TLVs only list labels/subchannels to exclude, this implies that all TLVs only list labels/subchannels to exclude, this implies that all
other labels are acceptable. other labels are acceptable.
skipping to change at page 8, line 26 skipping to change at page 7, line 32
acceptable. A Label Set is included when a node wishes to restrict acceptable. A Label Set is included when a node wishes to restrict
the label(s) that may be used downstream. the label(s) that may be used downstream.
On reception of a REQUEST message, the receiving node will restrict On reception of a REQUEST message, the receiving node will restrict
its choice of labels to one, which is in the Label Set. Nodes its choice of labels to one, which is in the Label Set. Nodes
capable of performing label conversion may also remove the Label Set capable of performing label conversion may also remove the Label Set
prior to forwarding the REQUEST message. If the node is unable to prior to forwarding the REQUEST message. If the node is unable to
pick a label from the Label Set or if there is a problem parsing the pick a label from the Label Set or if there is a problem parsing the
Label Set TLVs, then the request is terminated and a NOTIFICATION Label Set TLVs, then the request is terminated and a NOTIFICATION
message with a "Routing problem/Label Set" indication MUST be message with a "Routing problem/Label Set" indication MUST be
generated. It is a local matter if the Label Set is stored for later generated. It is a local matter if the Label Set is stored for later
selection on the MAPPING message or if the selection is made selection on the MAPPING message or if the selection is made
immediately for propagation in the MAPPING message. immediately for propagation in the MAPPING message.
On reception of a REQUEST message, the Label Set represented in the On reception of a REQUEST message, the Label Set represented in the
message is compared against the set of available labels at the message is compared against the set of available labels at the
downstream interface and the resulting intersecting Label Set is downstream interface and the resulting intersecting Label Set is
forwarded in a REQUEST message. When the resulting Label Set is forwarded in a REQUEST message. When the resulting Label Set is
empty, the REQUEST must be terminated, and a NOTIFICATION message, empty, the REQUEST must be terminated, and a NOTIFICATION message,
and a "Routing problem/Label Set" indication MUST be generated. Note and a "Routing problem/Label Set" indication MUST be generated. Note
that intersection is based on the physical labels (actual that intersection is based on the physical labels (actual
wavelength/band values) which may have different logical values on wavelength/band values) which may have different logical values on
different links, as a result it is the responsibility of the node to different links, as a result it is the responsibility of the node to
map these values so that they have a consistent physical meaning, or map these values so that they have a consistent physical meaning, or
to drop the particular values from the set if no suitable logical to drop the particular values from the set if no suitable logical
label value exists. label value exists.
When processing a MAPPING message at an intermediate node, the label When processing a MAPPING message at an intermediate node, the label
propagated upstream MUST fall within the Label Set. propagated upstream MUST fall within the Label Set.
Note, on reception of a MAPPING message a node that is incapable of Note, on reception of a MAPPING message a node that is incapable of
performing label conversion has no other choice than to use the same performing label conversion has no other choice than to use the same
physical label (wavelength/band) as received in the MAPPING message. physical label (wavelength/band) as received in the MAPPING message.
In this case, the use and propagation of a Label Set will In this case, the use and propagation of a Label Set will
significantly reduce the chances that this allocation will fail. significantly reduce the chances that this allocation will fail.
3. Bidirectional LSPs 3. Bidirectional LSPs
Bidirectional LSP setup is indicated by the presence of an Upstream Bidirectional LSP setup is indicated by the presence of an Upstream
Label in the REQUEST message. An Upstream Label has the same format Label in the REQUEST message. An Upstream Label has the same format
as the generalized label, see Section 2.2. Upstream Label uses type= as the generalized label, see Section 2.2. Upstream Label uses type
TBA = 0x0826.
3.1. Procedures 3.1. Procedures
The process of establishing a bidirectional LSP follows the The process of establishing a bidirectional LSP follows the
establishment of a unidirectional LSP with some additions. To establishment of a unidirectional LSP with some additions. To
support bidirectional LSPs an Upstream Label is added to the REQUEST support bidirectional LSPs an Upstream Label is added to the REQUEST
message. The Upstream Label MUST indicate a label that is valid for message. The Upstream Label MUST indicate a label that is valid for
forwarding at the time the REQUEST message is sent. forwarding at the time the REQUEST message is sent.
When a REQUEST message containing an Upstream Label is received, the When a REQUEST message containing an Upstream Label is received, the
skipping to change at page 9, line 46 skipping to change at page 9, line 8
transport data traffic associated with the LSP upstream towards the transport data traffic associated with the LSP upstream towards the
initiator. initiator.
When a bidirectional LSP is removed, both upstream and downstream When a bidirectional LSP is removed, both upstream and downstream
labels are invalidated and it is no longer valid to send data using labels are invalidated and it is no longer valid to send data using
the associated labels. the associated labels.
4. Notification on Label Error 4. Notification on Label Error
This section defines the Acceptable Label Set TLV to support This section defines the Acceptable Label Set TLV to support
Notification on Label Error per [GMPLS-SIG]. An Acceptable Label Set Notification on Label Error per [RFC3471]. An Acceptable Label Set
TLV uses a type value of TBA The remaining contents of the TLV have TLV uses a type value of 0x082a. The remaining contents of the TLV
the identical format as the Label Set TLV, see Section 2.5. have the identical format as the Label Set TLV, see Section 2.5.
Acceptable Label Set TLVs may be carried in NOTIFICATION messages. Acceptable Label Set TLVs may be carried in NOTIFICATION messages.
The procedures for defining an Acceptable Label Set follow the The procedures for defining an Acceptable Label Set follow the
procedures for defining a Label Set, see Section 2.5.1. procedures for defining a Label Set, see Section 2.5.1.
Specifically, an Acceptable Label Set is defined via one or more Specifically, an Acceptable Label Set is defined via one or more
Acceptable Label Set TLVs. Specific labels/subchannels can be added Acceptable Label Set TLVs. Specific labels/subchannels can be added
to or excluded from an Acceptable Label Set via Action zero (0) and to or excluded from an Acceptable Label Set via Action zero (0) and
one (1) TLVs respectively. Ranges of labels/subchannels can be added one (1) TLVs respectively. Ranges of labels/subchannels can be added
to or excluded from an Acceptable Label Set via Action two (2) and to or excluded from an Acceptable Label Set via Action two (2) and
three (3) TLVs respectively. When the Acceptable Label Set TLVs only three (3) TLVs respectively. When the Acceptable Label Set TLVs only
skipping to change at page 10, line 23 skipping to change at page 9, line 33
The inclusion of Acceptable Label Set TLVs is optional. If included, The inclusion of Acceptable Label Set TLVs is optional. If included,
the NOTIFICATION message SHOULD contain a "Routing the NOTIFICATION message SHOULD contain a "Routing
problem/Unacceptable label value" indication. The absence of problem/Unacceptable label value" indication. The absence of
Acceptable Label Set TLVs does not have any specific meaning. Acceptable Label Set TLVs does not have any specific meaning.
5. Explicit Label Control 5. Explicit Label Control
The Label ER-Hop TLV is defined as follows: The Label ER-Hop TLV is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (TBA by IANA) | Length | |0|0| Type (0x0829) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|U| Reserved | Label | |L|U| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (continued) | | Label (continued) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of L, U and Label parameters. See [RFC3471] for a description of L, U and Label parameters.
5.1. Procedures 5.1. Procedures
The Label ER-Hop follows a ER-Hop containing the IP address, or the The Label ER-Hop follows a ER-Hop containing the IP address, or the
interface identifier [MPLS-UNNUM], associated with the link on which interface identifier [MPLS-UNNUM], associated with the link on which
it is to be used. Up to two label ER-Hops may be present, one for it is to be used. Up to two label ER-Hops may be present, one for
the downstream label and one for the upstream label. The following the downstream label and one for the upstream label. The following
SHOULD result in "Bad EXPLICIT_ROUTE" errors: SHOULD result in "Bad EXPLICIT_ROUTE" errors:
- If the first label ER-Hop is not preceded by a ER-Hop
containing an IP address, or a interface identifier
[MPLS-UNNUM], associated with an output link.
- For a label ER-Hop to follow a ER-Hop that has the L-bit
set
- On unidirectional LSP setup, for there to be a label ER-Hop
with the U-bit set
- For there to be two label ER-Hops with the same U-bit values o If the first label ER-Hop is not preceded by a ER-Hop containing
an IP address, or a interface identifier [MPLS-UNNUM], associated
with an output link.
o For a label ER-Hop to follow a ER-Hop that has the L-bit set.
o On unidirectional LSP setup, for there to be a label ER-Hop with
the U-bit set.
o For there to be two label ER-Hops with the same U-bit values.
To support the label ER-Hop, a node must check to see if the ER-Hop To support the label ER-Hop, a node must check to see if the ER-Hop
following its associate address/interface is a label ER-Hop. If it following its associate address/interface is a label ER-Hop. If it
is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops
for bidirectional LSPs. If the U-bit of the ER-Hop being examined is for bidirectional LSPs. If the U-bit of the ER-Hop being examined is
clear (0), then value of the label is copied into a new Label Set clear (0), then value of the label is copied into a new Label Set
TLV. This Label Set TLV MUST be included on the corresponding TLV. This Label Set TLV MUST be included on the corresponding
outgoing REQUEST message. outgoing REQUEST message.
If the U-bit of the ER-Hop being examined is set (1), then value of If the U-bit of the ER-Hop being examined is set (1), then value of
skipping to change at page 11, line 41 skipping to change at page 11, line 5
information needed to construct the Label ER-Hop are outside the information needed to construct the Label ER-Hop are outside the
scope of this document. scope of this document.
6. Protection TLV 6. Protection TLV
The use of the Protection TLV is optional. The TLV is included to The use of the Protection TLV is optional. The TLV is included to
indicate specific protection attributes of an LSP. indicate specific protection attributes of an LSP.
The format of Protection Information TLV is: The format of Protection Information TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x0835) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags| |S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [RFC3471] for a description of parameters.
6.1. Procedures 6.1. Procedures
Transit nodes processing a REQUEST message containing a Protection Transit nodes processing a REQUEST message containing a Protection
TLV MUST verify that the requested protection can be satisfied by the TLV MUST verify that the requested protection can be satisfied by the
outgoing interface or tunnel (FA). If it cannot, the node MUST outgoing interface or tunnel (FA). If it cannot, the node MUST
generate a NOTIFICATION message, with a "Routing problem/Unsupported generate a NOTIFICATION message, with a "Routing problem/Unsupported
Link Protection" indication. Link Protection" indication.
7. Administrative Status Information 7. Administrative Status Information
skipping to change at page 12, line 25 skipping to change at page 11, line 35
Administrative Status Information is carried in the Admin Status TLV. Administrative Status Information is carried in the Admin Status TLV.
The TLV provides information related to the administrative state of a The TLV provides information related to the administrative state of a
particular LSP. The information is used in two ways. In the first, particular LSP. The information is used in two ways. In the first,
the TLV is carried in REQUEST and MAPPING messages to indicate the the TLV is carried in REQUEST and MAPPING messages to indicate the
administrative state of an LSP. In the second, the TLV is carried in administrative state of an LSP. In the second, the TLV is carried in
Notification message to request a change to the administrative state Notification message to request a change to the administrative state
of an LSP. of an LSP.
7.1. Admin Status TLV 7.1. Admin Status TLV
The use of the Admin Status TLV is optional. It uses Type = TBA. The The use of the Admin Status TLV is optional. It uses Type = 0x082b.
format of the TLV is: The format of the TLV is:
The format of Admin Status TLV in REQUEST, MAPPING and Notification The format of Admin Status TLV in REQUEST, MAPPING and Notification
Messages is: Messages is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x082b) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D| |R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [RFC3471] for a description of parameters.
7.2. REQUEST and MAPPING Message Procedures 7.2. REQUEST and MAPPING Message Procedures
The Admin Status TLV is used to notify each node along the path of The Admin Status TLV is used to notify each node along the path of
the status of the LSP. Each node processes status information based the status of the LSP. Each node processes status information based
on local policy and then propagated in the corresponding outgoing on local policy and then propagated in the corresponding outgoing
messages. The TLV is inserted in REQUEST messages at the discretion messages. The TLV is inserted in REQUEST messages at the discretion
of the ingress node. The absence of the TLV is the equivalent to of the ingress node. The absence of the TLV is the equivalent to
receiving a TLV containing values all set to zero. receiving a TLV containing values all set to zero.
Transit nodes receiving a REQUEST message containing an Admin Status Transit nodes receiving a REQUEST message containing an Admin Status
TLV, update their local state, take any appropriate local action TLV, update their local state, take any appropriate local action
based on the indicated status and then propagate the received Admin based on the indicated status and then propagate the received Admin
Status TLV in the outgoing REQUEST message. Status TLV in the outgoing REQUEST message.
Edge nodes receiving a REQUEST message containing an Admin Status Edge nodes receiving a REQUEST message containing an Admin Status
TLV, also update their local state and take any appropriate local TLV, also update their local state and take any appropriate local
action based on the indicated status. When the ADMIN Status TLV is action based on the indicated status. When the ADMIN Status TLV is
skipping to change at page 13, line 38 skipping to change at page 12, line 38
corresponding Request message. corresponding Request message.
7.2.1. Deletion procedure 7.2.1. Deletion procedure
In some circumstances, particularly optical networks, it is useful to In some circumstances, particularly optical networks, it is useful to
set the administrative status of an LSP before tearing it down. set the administrative status of an LSP before tearing it down.
In such circumstances the procedure SHOULD be followed when deleting In such circumstances the procedure SHOULD be followed when deleting
an LSP from the ingress: an LSP from the ingress:
o The ingress node precedes an LSP deletion by inserting an o The ingress node precedes an LSP deletion by inserting an Admin
Admin Status TLV in a Notification Message setting the Reflect Status TLV in a Notification Message setting the Reflect (R) and
(R) and Delete (D) bits. Delete (D) bits.
o Transit nodes process the Admin Status TLV by passing the o Transit nodes process the Admin Status TLV by passing the
Notification message. The egress node May respond with a Notification message. The egress node May respond with a
Notification message with the Admin Status TLV. Notification message with the Admin Status TLV.
o Upon receiving the Admin Status TLV with the Delete (D) bit o Upon receiving the Admin Status TLV with the Delete (D) bit set
set in the Notification message, the egress SHOULD respond in the Notification message, the egress SHOULD respond with a
with a LABEL WITHDRAW message and normal CR-LDP processing LABEL WITHDRAW message and normal CR-LDP processing takes place.
takes place.
In such circumstances the procedure SHOULD be followed when deleting In such circumstances the procedure SHOULD be followed when deleting
an LSP from the egress: an LSP from the egress:
o The egress node indicates its desire for deletion by inserting o The egress node indicates its desire for deletion by inserting an
an Admin Status TLV in a Notification message and setting Admin Status TLV in a Notification message and setting Delete (D)
Delete (D) bit. bit.
o Transit nodes process the Admin Status TLV as described above. o Transit nodes process the Admin Status TLV as described above.
o Upon receiving the Admin Status TLV with the Delete (D) bit o Upon receiving the Admin Status TLV with the Delete (D) bit set
set in the Notification message, the ingress node sends a in the Notification message, the ingress node sends a LABEL
LABEL RELEASE message downstream to remove the LSP and normal RELEASE message downstream to remove the LSP and normal CR-LDP
CR-LDP processing takes place. processing takes place.
7.3. Notification Message Procedures 7.3. Notification Message Procedures
Subsequent messaging Admin Status messaging may be performed by Subsequent messaging Admin Status messaging may be performed by
Notification Messages. The ingress may begin the propagation of a Notification Messages. The ingress may begin the propagation of a
Notification Message with an Admin Status TLV. Each subsequent node Notification Message with an Admin Status TLV. Each subsequent node
propagates the Notification with the Admin Status TLV from the propagates the Notification with the Admin Status TLV from the
ingress to the egress and then the egress node returns the ingress to the egress and then the egress node returns the
Notification messages back Upstream carrying the Admin Status TLV. Notification messages back Upstream carrying the Admin Status TLV.
Intermediate and egress nodes may trigger the setting of Intermediate and egress nodes may trigger the setting of
administrative status via the use of Notification messages. To administrative status via the use of Notification messages. To
accomplish this, an intermediate or egress node generates a accomplish this, an intermediate or egress node generates a
Notification message with the corresponding upstream notify session Notification message with the corresponding upstream notify session
information. The Admin Status TLV MUST be included in the session information. The Admin Status TLV MUST be included in the session
information, with the appropriate bit or bits set. The Reflect (R) information, with the appropriate bit or bits set. The Reflect (R)
skipping to change at page 15, line 14 skipping to change at page 14, line 14
8. Control Channel Separation 8. Control Channel Separation
This section provides the protocol specific formats and procedures to This section provides the protocol specific formats and procedures to
required support a control channel not being in-band with a data required support a control channel not being in-band with a data
channel. channel.
8.1. Interface Identification 8.1. Interface Identification
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 REQUEST message. The choice of the data interface is indicated of the REQUEST message. The choice of the data interface is
by the sender of the REQUEST message by including the data channel's indicated by the sender of the REQUEST message by including the data
interface identifier in the message using a new Interface TLV. type. channel's interface identifier in the message using a new Interface
For bidirectional LSPs, the sender chooses the data interface in each TLV type. For bidirectional LSPs, the sender chooses the data
direction. In all cases but bundling, the upstream interface is interface in each direction. In all cases but bundling, the upstream
implied by the downstream interface. For bundling, the REQUEST interface is implied by the downstream interface. For bundling, the
sender explicitly identifies the component interface used in each REQUEST sender explicitly identifies the component interface used in
direction. each direction.
8.1.1. Interface ID TLV 8.1.1. Interface ID TLV
The format of IPV4 Interface ID in REQUEST, MAPPING Messages is: The format of IPV4 Interface ID in REQUEST, MAPPING Messages is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address | | IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID | | Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [GMLPS-SIG] | | Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of IPV6 Interface ID TLV in REQUEST, MAPPING Messages is: The format of IPV6 Interface ID TLV in REQUEST, MAPPING Messages is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address | | IPv6 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID | | Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [GMPLS-SIG] | | Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
See [GMPLS-SIG] for a description of parameters.
See [RFC3212] for a description of signaling address. See [GMPLS- See [RFC3212] for a description of signaling address. See [RFC3471]
SIG] for a description of parameters and encoding of TLVs. for a description of parameters and encoding of TLVs.
8.1.2. Procedures 8.1.2. Procedures
An IF_ID TLV is used on links where there is not a one-to- one An IF_ID TLV is used on links where there is not a one-to-one
association of a control channel to a data channel, see [GMPLS- SIG]. association of a control channel to a data channel, see [RFC3471].
The LDP session uses the IF_ID TLV to identify the data channel(s) The LDP session uses the IF_ID TLV to identify the data channel(s)
associated with the LSP. For a unidirectional LSP, a downstream data associated with the LSP. For a unidirectional LSP, a downstream data
channel MUST be indicated. For bidirectional LSPs, a common channel MUST be indicated. For bidirectional LSPs, a common
downstream and upstream data channel is normally indicated. In the downstream and upstream data channel is normally indicated. In the
special case where a bidirectional LSP that traverses a bundled link, special case where a bidirectional LSP that traverses a bundled link,
it is possible to specify a downstream data channel that differs from it is possible to specify a downstream data channel that differs from
the upstream data channel. Data channels are specified from the the upstream data channel. Data channels are specified from the
viewpoint of the sender of a REQUEST message. The IF_ID TLV SHOULD viewpoint of the sender of a REQUEST message. The IF_ID TLV SHOULD
NOT be used when no TLVs are needed. NOT be used when no TLVs are needed.
skipping to change at page 17, line 15 skipping to change at page 16, line 9
8.2. Errored Interface Identification 8.2. Errored Interface Identification
There are cases where it is useful to indicate a specific interface There are cases where it is useful to indicate a specific interface
associated with an error. To support these cases the IF_ID Status associated with an error. To support these cases the IF_ID Status
TLV are defined. TLV are defined.
8.2.1. IF_ID Status TLVs 8.2.1. IF_ID Status TLVs
The format of the IPv4 IF_ID Status TLV is: The format of the IPv4 IF_ID Status TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x082f) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address | | IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID Status TLV is: The format of the IPv6 IF_ID Status TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBA by IANA) | Length | |U|F| Type (0x0830) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Error Node Address | | IPv6 Error Node Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3036] for a description of status code value fields. See [RFC3036] for a description of status code value fields. See
See [GMPLS-SIG] for a description of parameters and encoding of [RFC3471] for a description of parameters and encoding of TLVs.
TLVs.
8.2.2. Procedures 8.2.2. Procedures
Nodes wishing to indicate that an error is related to a specific Nodes wishing to indicate that an error is related to a specific
interface SHOULD use the appropriate IF_ID Status TLV in the interface SHOULD use the appropriate IF_ID Status TLV in the
corresponding LABEL WITHDRAW or LABEL RELEASE message. IF_ID Status corresponding LABEL WITHDRAW or LABEL RELEASE message. IF_ID Status
TLV SHOULD be generated and processed as any other Status TLV, see TLV SHOULD be generated and processed as any other Status TLV, see
[RFC3036]. [RFC3036].
9. Fault Handling 9. Fault Handling
In optical transport networks, failures in the out-of-fiber signaling In optical transport networks, failures in the out-of-fiber signaling
communication or optical control plane should not have service impact communication or optical control plane should not have service impact
on the existing optical connections. Under such circumstances, a on the existing optical connections. Under such circumstances, a
mechanism MUST exist to detect a signaling communication failure and mechanism MUST exist to detect a signaling communication failure and
a recovery procedure SHALL guarantee connection integrity at both a recovery procedure SHALL guarantee connection integrity at both
ends of the signaling channel. ends of the signaling channel.
The LDP Fault tolerant draft [LDP-FT] specifies the procedures for The LDP Fault tolerant document [LDP-FT] specifies the procedures for
recovering LDP and CR-LDP sessions under failure. Please refer to his recovering LDP and CR-LDP sessions under failure. Please refer to
draft for procedures on recovering optical connections. Currently his document for procedures on recovering optical connections.
the Fault tolerant draft covers many of the common failure modes for Currently the Fault tolerant document covers many of the common
a separated control and data plane. failure modes for a separated control and data plane.
10. Acknowledgments 10. Acknowledgments
This draft is the work of numerous authors and consists of a This document is the work of numerous authors and consists of a
composition of a number of previous drafts in this area. A list of composition of a number of previous documents in this area.
the drafts from which material and ideas were incorporated follows:
draft-saha-rsvp-optical-signaling-00.txt
draft-lang-mpls-rsvp-oxc-00.txt
draft-kompella-mpls-optical-00.txt
draft-fan-mpls-lambda-signaling-00.txt
Valuable comments and input were received from a number of people, Valuable comments and input were received from a number of people,
notably Adrian Farrel. notably Adrian Farrel.
11. Security Considerations 11. Security Considerations
This draft introduce no new security considerations to [RFC3212]. This document introduces no new security considerations to [RFC3212].
12. IANA Considerations 12. IANA Considerations
This draft uses the LDP [RFC3036] name spaces, see This document uses the LDP [RFC3036] name spaces, see
http://www.iana.org/assignments/ldp-namespaces, which require http://www.iana.org/assignments/ldp-namespaces, which lists the
assignment for the following TLVs: assignments for the following TLVs:
o Generalized Label Request (TLV TBA) o Generalized Label Request (TLV 0x0824)
o Generalized Label (TLV TBA) o Generalized Label (TLV 0x0825)
o Upstream Label (TLV TBA) o Upstream Label (TLV 0x0826)
o Label Set (TLV TBA) o Label Set (TLV 0x0827)
o Waveband Label (TLV TBA) o Waveband Label (TLV 0x0828)
o ER-Hop (TLV TBA) o ER-Hop (TLV 0x0829)
o Acceptable Label Set (TLV TBA) o Acceptable Label Set (TLV 0x082a)
o Admin Status (TLV TBA) o Admin Status (TLV 0x082b)
o Interface ID (TLV TBA) o Interface ID (TLV 0x082c)
o IPV4 Interface ID (TLV TBA) o IPV4 Interface ID (TLV 0x082d)
o IPV6 Interface ID (TLV TBA) o IPV6 Interface ID (TLV 0x082e)
o IPv4 IF_ID Status (TLV TBA) o IPv4 IF_ID Status (TLV 0x082f)
o IPv6 IF_ID Status (TLV TBA) o IPv6 IF_ID Status (TLV 0x0830)
o Protection (TLV 0x0835)
13. Intellectual Property Considerations 13. 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
skipping to change at page 20, line 33 skipping to change at page 18, line 33
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
14. References 14. References
14.1. Normative References 14.1. Normative References
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Signaling Functional Description", Internet Draft, Requirement Levels," BCP 14, RFC 2119. March 1997.
draft-ietf-mpls-generalized-signaling-09.txt,
August 2002.
[RFC3036] Andersson et al., "LDP Specification", [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
RFC 3036. and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[RFC3212] Jamoussi et al., "Constraint-Based LSP Setup using LDP", [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R.,
RFC 3212, January 2002. Wu, L., Doolan, P., Worster, T., Feldman, N.,
Fredette, A., Girish, M., Gray, E., Heinanen, J.,
Kilty, T. and A. Malis, "Constraint-Based LSP Setup
using LDP", RFC 3212, January 2002.
14.2. Informative References [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - 14.2. Informative References
RSVP-TE Extensions", Internet Draft,
draft-ietf-mpls-generalized-rsvp-te-08.txt,
August 2002.
[LDP-FT] Farrel, A. et al, "Fault Tolerance for LDP [LDP-FT] Farrel, A., et al, "Fault Tolerance for LDP and CR-
and CR-LDP", Internet Draft, LDP", Work in Progress.
draft-ietf-mpls-ldp-ft-02.txt,
May 2001.
[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with [MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Internet Draft, MPLS TE", Work in Progress.
draft-ietf-mpls-lsp-hierarchy-02.txt, Sep., 2001.
[MPLS-UNNUM] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling [MPLS-UNNUM] Kompella, K., Rekhter, Y. and A. Kullberg,
Unnumbered Links in CR-LDP", Internet Draft, "Signalling Unnumbered Links in CR-LDP", Work in
draft-ietf-mpls-crldp-unnum-07.txt, July 2002. Progress.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," [RFC2026] Bradner, S., "The Internet Standards Process --
RFC 2026. Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol
Requirement Levels," RFC 2119. Label Switching (GMPLS) Signaling - Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 3473, January 2003.
15. Contributors 15. Contributors
Peter Ashwood-Smith Peter Ashwood-Smith
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763 4534 Phone: +1 613 763 4534
Email: petera@nortelnetworks.com EMail: petera@nortelnetworks.com
Ayan Banerjee Ayan Banerjee
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972-3645 Phone: +1 408 972-3645
Email: abanerjee@calient.net EMail: abanerjee@calient.net
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Phone: +1 703 847-1801 Phone: +1 703 847-1801
Email: lberger@movaz.com EMail: lberger@movaz.com
Greg Bernstein Greg Bernstein
Ciena Corporation EMail: gregb@grotto-networking.com
10480 Ridgeview Court
Cupertino, CA 94014
Phone: +1 408 366 4713
Email: greg@ciena.com
Yanhe Fan Yanhe Fan
Axiowave Networks, Inc. Axiowave Networks, Inc.
200 Nickerson Road 200 Nickerson Road
Marlborough, MA 01752 Marlborough, MA 01752
Phone: + 1 774 348 4627 Phone: + 1 774 348 4627
Email: yfan@axiowave.com EMail: yfan@axiowave.com
Don Fedyk Don Fedyk
Nortel Networks Corp. Nortel Networks Corp.
600 Technology Park 600 Technology Park
Billerica MA 01821 Billerica MA 01821
Phone: +1 978 288 3041 Phone: +1 978 288 3041
Fax: +1 978 288 0620 Fax: +1 978 288 0620
Email: dwfedyk@nortelnetworks.com EMail: dwfedyk@nortelnetworks.com
Jonathan P. Lang Jonathan P. Lang
Calient Networks EMail: jplang@ieee.org
25 Castilian
Goleta, CA 93117
Email: jplang@calient.net
Eric Mannie Eric Mannie
KPNQwest Independent Consultant
Terhulpsesteenweg 6A 2 Avenue de la Folle Chanson
1560 Hoeilaart - Belgium 1050 Brussels
Phone: +32 2 658 56 52 Belgium
Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18 EMail: eric_mannie@hotmail.com
Email: eric.mannie@kpnqwest.com
Bala Rajagopalan Bala Rajagopalan
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4237 Phone: +1 732 923 4237
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: braja@tellium.com EMail: braja@tellium.com
Debanjan Saha Debanjan Saha
Tellium Optical Systems EMail: debanjan@acm.org
2 Crescent Place
Oceanport, NJ 07757-0901
Phone: +1 732 923 4264
Fax: +1 732 923 9804
Email: dsaha@tellium.com
Vishal Sharma Vishal Sharma
Metanoia, Inc. Metanoia, Inc.
335 Elan Village Lane, Unit 203 1600 Villa Street, Unit 352
San Jose, CA 95134-2539 Mountain View, CA 94041-1174
Phone: +1 408-943-1794
Email: v.sharma@ieee.org Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Voice: +1 978 244 8143
Email: swallow@cisco.com Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang Z. Bo Tang
Tellium, Inc. EMail: botang01@yahoo.com
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Phone: +1 732 923 4231
Fax: +1 732 923 9804
Email: btang@tellium.com
16. Contact Addresses 16. Editors' Addresses
Peter Ashwood-Smith Peter Ashwood-Smith
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763 4534 Phone: +1 613 763 4534
Email: petera@nortelnetworks.com EMail: petera@nortelnetworks.com
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Phone: +1 703 847-1801 Phone: +1 703 847-1801
Email: lberger@movaz.com EMail: lberger@movaz.com
Generated on: Wed Aug 28 10:40:59 2002 17. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 98 change blocks. 
361 lines changed or deleted 339 lines changed or added

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