draft-ietf-mpls-rsvp-lsp-tunnel-08.txt   draft-ietf-mpls-rsvp-lsp-tunnel-09.txt 
Network Working Group Daniel O. Awduche Network Working Group Daniel O. Awduche
Internet Draft Movaz Networks, Inc. Internet Draft Movaz Networks, Inc.
Expiration Date: August 2001 Expiration Date: February 2002
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
Der-Hwa Gan Der-Hwa Gan
Juniper Networks, Inc. Juniper Networks, Inc.
Tony Li Tony Li
Procket Networks, Inc. Procket Networks, Inc.
Vijay Srinivasan Vijay Srinivasan
Cosine Communications, Inc. Cosine Communications, Inc.
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
February 2001 August 2001
RSVP-TE: Extensions to RSVP for LSP Tunnels RSVP-TE: Extensions to RSVP for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt draft-ietf-mpls-rsvp-lsp-tunnel-09.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. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 4, line 22 skipping to change at page 4, line 22
5 Hello Extension ........................................ 53 5 Hello Extension ........................................ 53
5.1 Hello Message Format ................................... 54 5.1 Hello Message Format ................................... 54
5.2 HELLO Object formats ................................... 54 5.2 HELLO Object formats ................................... 54
5.2.1 HELLO REQUEST object ................................... 54 5.2.1 HELLO REQUEST object ................................... 54
5.2.2 HELLO ACK object ....................................... 55 5.2.2 HELLO ACK object ....................................... 55
5.3 Hello Message Usage .................................... 55 5.3 Hello Message Usage .................................... 55
5.4 Multi-Link Considerations .............................. 57 5.4 Multi-Link Considerations .............................. 57
5.5 Compatibility .......................................... 57 5.5 Compatibility .......................................... 57
6 Security Considerations ................................ 58 6 Security Considerations ................................ 58
7 IANA Considerations .................................... 58 7 IANA Considerations .................................... 58
8 Intellectual Property Considerations ................... 59 7.1 Message Types .......................................... 59
9 Acknowledgments ........................................ 59 7.2 Class Numbers and C-Types .............................. 59
10 References ............................................. 59 7.3 Error Codes and Globally-Defined Error Value Sub-Codes . 60
11 Authors' Addresses ..................................... 60 7.4 Subobject Definitions .................................. 61
8 Intellectual Property Considerations ................... 62
9 Acknowledgments ........................................ 62
10 References ............................................. 62
11 Authors' Addresses ..................................... 63
1. Introduction 1. Introduction
Section 2.9 of the MPLS architecture [2] defines a label distribution Section 2.9 of the MPLS architecture [2] defines a label distribution
protocol as a set of procedures by which one Label Switched Router protocol as a set of procedures by which one Label Switched Router
(LSR) informs another of the meaning of labels used to forward (LSR) informs another of the meaning of labels used to forward
traffic between and through them. The MPLS architecture does not traffic between and through them. The MPLS architecture does not
assume a single label distribution protocol. This document is a assume a single label distribution protocol. This document is a
specification of extensions to RSVP for establishing label switched specification of extensions to RSVP for establishing label switched
paths (LSPs) in Multi-protocol Label Switching (MPLS) networks. paths (LSPs) in Multi-protocol Label Switching (MPLS) networks.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
Finally, a SESSION_ATTRIBUTE object can be added to Path messages to Finally, a SESSION_ATTRIBUTE object can be added to Path messages to
aid in session identification and diagnostics. Additional control aid in session identification and diagnostics. Additional control
information, such as setup and hold priorities, resource affinities information, such as setup and hold priorities, resource affinities
(see [3]), and local-protection, are also included in this object. (see [3]), and local-protection, are also included in this object.
Routers along the path may use the setup and hold priorities along Routers along the path may use the setup and hold priorities along
with SENDER_TSPEC and any POLICY_DATA objects contained in Path with SENDER_TSPEC and any POLICY_DATA objects contained in Path
messages as input to policy control. For instance, in the traffic messages as input to policy control. For instance, in the traffic
engineering application, it is very useful to use the Path message as engineering application, it is very useful to use the Path message as
a means of verifying that bandwidth exists at a particular priority a means of verifying that bandwidth exists at a particular priority
along an entire path before pre-empting any lower priority along an entire path before preempting any lower priority
reservations. If a Path message is allowed to progress when there reservations. If a Path message is allowed to progress when there
are insufficient resources, the there is a danger that lower priority are insufficient resources, then there is a danger that lower
reservations downstream of this point will unnecessarily be pre- priority reservations downstream of this point will unnecessarily be
empted in a futile attempt to service this request. preempted in a futile attempt to service this request.
When the EXPLICIT_ROUTE object (ERO) is present, the Path message is When the EXPLICIT_ROUTE object (ERO) is present, the Path message is
forwarded towards its destination along a path specified by the ERO. forwarded towards its destination along a path specified by the ERO.
Each node along the path records the ERO in its path state block. Each node along the path records the ERO in its path state block.
Nodes may also modify the ERO before forwarding the Path message. In Nodes may also modify the ERO before forwarding the Path message. In
this case the modified ERO SHOULD be stored in the path state block this case the modified ERO SHOULD be stored in the path state block
in addition to the received ERO. in addition to the received ERO.
The LABEL_REQUEST object requests intermediate routers and receiver The LABEL_REQUEST object requests intermediate routers and receiver
nodes to provide a label binding for the session. If a node is nodes to provide a label binding for the session. If a node is
skipping to change at page 12, line 9 skipping to change at page 12, line 9
Label Map" (ILM), which is used to map incoming labeled packets to a Label Map" (ILM), which is used to map incoming labeled packets to a
"Next Hop Label Forwarding Entry" (NHLFE), see [2]. "Next Hop Label Forwarding Entry" (NHLFE), see [2].
When the Resv message propagates upstream to the sender node, a When the Resv message propagates upstream to the sender node, a
label-switched path is effectively established. label-switched path is effectively established.
2.3. Service Classes 2.3. Service Classes
This document does not restrict the type of Integrated Service This document does not restrict the type of Integrated Service
requests for reservations. However, an implementation SHOULD support requests for reservations. However, an implementation SHOULD support
the Controlled-Load service [4] and the Class-of-Service service, see the Controlled-Load service [4] and the Null Service [16].
Section 4.8.
2.4. Reservation Styles 2.4. Reservation Styles
The receiver node can select from among a set of possible reservation The receiver node can select from among a set of possible reservation
styles for each session, and each RSVP session must have a particular styles for each session, and each RSVP session must have a particular
style. Senders have no influence on the choice of reservation style. style. Senders have no influence on the choice of reservation style.
The receiver can choose different reservation styles for different The receiver can choose different reservation styles for different
LSPs. LSPs.
An RSVP session can result in one or more LSPs, depending on the An RSVP session can result in one or more LSPs, depending on the
skipping to change at page 15, line 42 skipping to change at page 15, line 42
2.6. Path MTU 2.6. Path MTU
Standard RSVP [1] and Int-Serv [11] provide the RSVP sender with the Standard RSVP [1] and Int-Serv [11] provide the RSVP sender with the
minimum MTU available between the sender and the receiver. This path minimum MTU available between the sender and the receiver. This path
MTU identification capability is also provided for LSPs established MTU identification capability is also provided for LSPs established
via RSVP. via RSVP.
Path MTU information is carried, depending on which is present, in Path MTU information is carried, depending on which is present, in
the Integrated Services or Class-of-Service objects. When using the Integrated Services or Class-of-Service objects. When using
Integrated Services objects, path MTU is provided based on the Integrated Services objects, path MTU is provided based on the
procedures defined in [11]. Path MTU identification when using procedures defined in [11]. Path MTU identification when using Null
Class-of-Service objects is defined in Section 4.8. Service objects is defined in [16].
With standard RSVP, the path MTU information is used by the sender to With standard RSVP, the path MTU information is used by the sender to
check which IP packets exceed the path MTU. For packets that exceed check which IP packets exceed the path MTU. For packets that exceed
the path MTU, the sender either fragments the packets or, when the IP the path MTU, the sender either fragments the packets or, when the IP
datagram has the "Don't Fragment" bit set, issues an ICMP destination datagram has the "Don't Fragment" bit set, issues an ICMP destination
unreachable message. This path MTU related handling is also required unreachable message. This path MTU related handling is also required
for LSPs established via RSVP. for LSPs established via RSVP.
The following algorithm applies to all unlabeled IP datagrams and to The following algorithm applies to all unlabeled IP datagrams and to
any labeled packets which the node knows to be IP datagrams, to which any labeled packets which the node knows to be IP datagrams, to which
skipping to change at page 17, line 17 skipping to change at page 17, line 17
Five new objects are defined in this section: Five new objects are defined in this section:
Object name Applicable RSVP messages Object name Applicable RSVP messages
--------------- ------------------------ --------------- ------------------------
LABEL_REQUEST Path LABEL_REQUEST Path
LABEL Resv LABEL Resv
EXPLICIT_ROUTE Path EXPLICIT_ROUTE Path
RECORD_ROUTE Path, Resv RECORD_ROUTE Path, Resv
SESSION_ATTRIBUTE Path SESSION_ATTRIBUTE Path
New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, and
FILTER_SPEC, FLOWSPEC objects. FILTER_SPEC, objects.
Detailed descriptions of the new objects are given in later sections. Detailed descriptions of the new objects are given in later sections.
All new objects are OPTIONAL with respect to RSVP. An implementation All new objects are OPTIONAL with respect to RSVP. An implementation
can choose to support a subset of objects. However, the can choose to support a subset of objects. However, the
LABEL_REQUEST and LABEL objects are mandatory with respect to this LABEL_REQUEST and LABEL objects are mandatory with respect to this
specification. specification.
The LABEL and RECORD_ROUTE objects, are sender specific. In Resv The LABEL and RECORD_ROUTE objects, are sender specific. In Resv
messages they MUST appear after the associated FILTER_SPEC and prior messages they MUST appear after the associated FILTER_SPEC and prior
to any subsequent FILTER_SPEC. to any subsequent FILTER_SPEC.
skipping to change at page 20, line 7 skipping to change at page 20, line 7
In the case of ATM, one further condition applies. Some ATM nodes In the case of ATM, one further condition applies. Some ATM nodes
are not capable of merging streams. These nodes MAY indicate this by are not capable of merging streams. These nodes MAY indicate this by
setting a bit in the label request to zero. The M-bit in the setting a bit in the label request to zero. The M-bit in the
LABEL_REQUEST object of C-Type 2, label request with ATM label range, LABEL_REQUEST object of C-Type 2, label request with ATM label range,
serves this purpose. The M-bit SHOULD be set by nodes which are serves this purpose. The M-bit SHOULD be set by nodes which are
merge capable. If for any senders the M-bit is not set, the merge capable. If for any senders the M-bit is not set, the
downstream node MUST assign unique labels to those senders. downstream node MUST assign unique labels to those senders.
Once a label is allocated, the node formats a new LABEL object. The Once a label is allocated, the node formats a new LABEL object. The
node then sends the new LABEL object as part of the Resv message to node then sends the new LABEL object as part of the Resv message to
the previous hop. The LABEL object SHOULD be kept in the Reservation the previous hop. The node SHOULD be prepared to forward packets
State Block. It is then used in the next Resv refresh event for carrying the assigned label prior to sending the Resv message. The
formatting the Resv message. LABEL object SHOULD be kept in the Reservation State Block. It is
then used in the next Resv refresh event for formatting the Resv
message.
A node is expected to send a Resv message before its refresh timers A node is expected to send a Resv message before its refresh timers
expire if the contents of the LABEL object change. expire if the contents of the LABEL object change.
4.1.1.2. Upstream 4.1.1.2. Upstream
A node uses the label carried in the LABEL object as the outgoing A node uses the label carried in the LABEL object as the outgoing
label associated with the sender. The router allocates a new label label associated with the sender. The router allocates a new label
and binds it to the incoming interface of this session/sender. This and binds it to the incoming interface of this session/sender. This
is the same interface that the router uses to forward Resv messages is the same interface that the router uses to forward Resv messages
skipping to change at page 27, line 28 skipping to change at page 27, line 28
The L bit is an attribute of the subobject. The L bit is set The L bit is an attribute of the subobject. The L bit is set
if the subobject represents a loose hop in the explicit route. if the subobject represents a loose hop in the explicit route.
If the bit is not set, the subobject represents a strict hop in If the bit is not set, the subobject represents a strict hop in
the explicit route. the explicit route.
Type Type
The Type indicates the type of contents of the subobject. The Type indicates the type of contents of the subobject.
Currently defined values are: Currently defined values are:
0 Reserved
1 IPv4 prefix 1 IPv4 prefix
2 IPv6 prefix 2 IPv6 prefix
32 Autonomous system number 32 Autonomous system number
Length Length
The Length contains the total length of the subobject in bytes, The Length contains the total length of the subobject in bytes,
including the L, Type and Length fields. The Length MUST be at including the L, Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4. least 4, and MUST be a multiple of 4.
skipping to change at page 36, line 16 skipping to change at page 36, line 16
128 128
Flags Flags
0x01 Local protection available 0x01 Local protection available
Indicates that the link downstream of this node is Indicates that the link downstream of this node is
protected via a local repair mechanism. This flag can protected via a local repair mechanism. This flag can
only be set if the Local protection flag was set in the only be set if the Local protection flag was set in the
SESSION_ATTRIBUTE object of the cooresponding Path SESSION_ATTRIBUTE object of the corresponding Path
nessage. message.
0x02 Local protection in use 0x02 Local protection in use
Indicates that a local repair mechanism is in use to Indicates that a local repair mechanism is in use to
maintain this tunnel (usually in the face of an outage maintain this tunnel (usually in the face of an outage
of the link it was previously routed over). of the link it was previously routed over).
4.4.1.3. Subobject 0x03, Label 4.4.1.3. Subobject 3, Label
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | C-Type | | Type | Length | Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of Label Object | | Contents of Label Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
skipping to change at page 45, line 12 skipping to change at page 45, line 12
The format of the LSP_TUNNEL_IPv6 FILTER_SPEC object is identical to The format of the LSP_TUNNEL_IPv6 FILTER_SPEC object is identical to
the LSP_TUNNEL_IPv6 SENDER_TEMPLATE object. the LSP_TUNNEL_IPv6 SENDER_TEMPLATE object.
4.6.4. Reroute and Bandwidth Increase Procedure 4.6.4. Reroute and Bandwidth Increase Procedure
This section describes how to setup a tunnel that is capable of This section describes how to setup a tunnel that is capable of
maintaining resource reservations (without double counting) while it maintaining resource reservations (without double counting) while it
is being rerouted or while it is attempting to increase its is being rerouted or while it is attempting to increase its
bandwidth. In the initial Path message, the ingress node forms a bandwidth. In the initial Path message, the ingress node forms a
SESSION object, assigns a Tunnel_ID, and places its IPv4 address in SESSION object, assigns a Tunnel_ID, and places its IPv4 address in
the Extended_Tunnel_ID It also forms a SENDER_TEMPLATE and assigns a the Extended_Tunnel_ID. It also forms a SENDER_TEMPLATE and assigns
LSP_ID. Tunnel setup then proceeds according to the normal procedure. a LSP_ID. Tunnel setup then proceeds according to the normal
procedure.
On receipt of the Path message, the egress node sends a Resv message On receipt of the Path message, the egress node sends a Resv message
with the STYLE Shared Explicit toward the ingress node. with the STYLE Shared Explicit toward the ingress node.
When an ingress node with an established path wants to change that When an ingress node with an established path wants to change that
path, it forms a new Path message as follows. The existing SESSION path, it forms a new Path message as follows. The existing SESSION
object is used. In particular the Tunnel_ID and Extended_Tunnel_ID object is used. In particular the Tunnel_ID and Extended_Tunnel_ID
are unchanged. The ingress node picks a new LSP_ID to form a new are unchanged. The ingress node picks a new LSP_ID to form a new
SENDER_TEMPLATE. It creates an EXPLICIT_ROUTE object for the new SENDER_TEMPLATE. It creates an EXPLICIT_ROUTE object for the new
route. The new Path message is sent. The ingress node refreshes route. The new Path message is sent. The ingress node refreshes
both the old and new path messages both the old and new path messages.
The egress node responds with a Resv message with an SE flow The egress node responds with a Resv message with an SE flow
descriptor formatted as: descriptor formatted as:
<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC> <FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT> <new_LABEL_OBJECT>
(Note that if the PHOPs are different, then two messages are sent (Note that if the PHOPs are different, then two messages are sent
each with the appropriate FILTER_SPEC and LABEL_OBJECT.) each with the appropriate FILTER_SPEC and LABEL_OBJECT.)
skipping to change at page 50, line 44 skipping to change at page 50, line 44
If the requested bandwidth is not available a PathErr message is If the requested bandwidth is not available a PathErr message is
returned with an Error Code of 01, Admission Control Failure, and an returned with an Error Code of 01, Admission Control Failure, and an
Error Value of 0x0002. The first 0 in the Error Value indicates a Error Value of 0x0002. The first 0 in the Error Value indicates a
globally defined subcode and is not informational. The 002 indicates globally defined subcode and is not informational. The 002 indicates
"requested bandwidth unavailable". "requested bandwidth unavailable".
If the requested bandwidth is less than the unused bandwidth then If the requested bandwidth is less than the unused bandwidth then
processing is complete. If the requested bandwidth is available, but processing is complete. If the requested bandwidth is available, but
is in use by lower priority sessions, then lower priority sessions is in use by lower priority sessions, then lower priority sessions
(beginning with the lowest priority) MAY be pre-empted to free the (beginning with the lowest priority) MAY be preempted to free the
necessary bandwidth. necessary bandwidth.
When pre-emption is supported, each pre-empted reservation triggers a When preemption is supported, each preempted reservation triggers a
TC_Preempt() upcall to local clients, passing a subcode that TC_Preempt() upcall to local clients, passing a subcode that
indicates the reason. A ResvErr and/or PathErr with the code "Policy indicates the reason. A ResvErr and/or PathErr with the code "Policy
Control failure" SHOULD be sent toward the downstream receivers and Control failure" SHOULD be sent toward the downstream receivers and
upstream senders. upstream senders.
The support of local-protection is OPTIONAL. A node may recognize The support of local-protection is OPTIONAL. A node may recognize
the local-protection Flag but may be unable to perform the requested the local-protection Flag but may be unable to perform the requested
operation. In this case, the node SHOULD pass the information operation. In this case, the node SHOULD pass the information
downstream unchanged. downstream unchanged.
The recording of the Label subobject in the ROUTE_RECORD object is The recording of the Label subobject in the ROUTE_RECORD object is
controlled by the label-recording-desired flag in the controlled by the label-recording-desired flag in the
SESSION_ATTRIBUTE object. Since the Label subobject is not needed SESSION_ATTRIBUTE object. Since the Label subobject is not needed
for all applications, it is not automatically recorded. The flag for all applications, it is not automatically recorded. The flag
allows applications to request this only when needed. allows applications to request this only when needed.
The contents of the Session Name field are a string, typically of The contents of the Session Name field are a string, typically of
displayable characters. The Length MUST always be a multiple of 4 display-able characters. The Length MUST always be a multiple of 4
and MUST be at least 8. For an object length that is not a multiple and MUST be at least 8. For an object length that is not a multiple
of 4, the object is padded with trailing NULL characters. The Name of 4, the object is padded with trailing NULL characters. The Name
Length field contains the actual string length. Length field contains the actual string length.
4.7.4. Resource Affinity Procedures 4.7.4. Resource Affinity Procedures
Resource classes and resource class affinities are described in [3]. Resource classes and resource class affinities are described in [3].
In this document we use the briefer term resource affinities for the In this document we use the briefer term resource affinities for the
latter term. Resource classes can be associated with links and latter term. Resource classes can be associated with links and
advertised in routing protocols. Resource class affinities are used advertised in routing protocols. Resource class affinities are used
skipping to change at page 58, line 31 skipping to change at page 58, line 31
document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are
defined. Each of these objects contain subobjects. This section defined. Each of these objects contain subobjects. This section
defines the rules for the assignment of subobject numbers. This defines the rules for the assignment of subobject numbers. This
section uses the terminology of BCP 26 "Guidelines for Writing an section uses the terminology of BCP 26 "Guidelines for Writing an
IANA Considerations Section in RFCs" [15]. IANA Considerations Section in RFCs" [15].
EXPLICIT_ROUTE Subobject Type EXPLICIT_ROUTE Subobject Type
EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies
the function of the subobject. There are no range restrictions. the function of the subobject. There are no range restrictions.
All possible values except zero are available for assignment. All possible values are available for assignment.
Following the policies outlined in [15], subobject types in the Following the policies outlined in [15], subobject types in the
range 0x00 - 0x3F are allocated through an IETF Consensus action, range 0 - 63 (0x00 - 0x3F) are allocated through an IETF Consensus
codes in the range 00x40 - 0x5F are allocated as First Come First action, codes in the range 64 - 95 (0x40 - 0x5F) are allocated as
Served, and codes in the range 0x60 - 0x7F are reserved for First Come First Served, and codes in the range 96 - 127 (0x60 -
Private Use. 0x7F) are reserved for Private Use.
ROUTE_RECORD Subobject Type ROUTE_RECORD Subobject Type
ROUTE_RECORD Subobject Type is an 8-bit number that identifies the ROUTE_RECORD Subobject Type is an 8-bit number that identifies the
function of the subobject. There are no range restrictions. All function of the subobject. There are no range restrictions. All
possible values except zero are available for assignment. possible values are available for assignment.
Following the policies outlined in [15], subobject types in the Following the policies outlined in [15], subobject types in the
range 0x00 - 0x7F are allocated through an IETF Consensus action, range 0 - 127 (0x00 - 0x7F) are allocated through an IETF
codes in the range 00x80 - 0xBF are allocated as First Come First Consensus action, codes in the range 128 - 191 (0x80 - 0xBF) are
Served, and codes in the range 0xC0 - 0xFF are reserved for allocated as First Come First Served, and codes in the range 192 -
Private Use. 255 (0xC0 - 0xFF) are reserved for Private Use.
The following assignments are made in this document.
7.1. Message Types
Message Message
Number Name
20 Hello
7.2. Class Numbers and C-Types
Class Class
Number Name
1 SESSION
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
10 FILTER_SPEC
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
11 SENDER_TEMPLATE
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
16 RSVP_LABEL
Class Types or C-Types:
1 Type 1 Label
19 LABEL_REQUEST
Class Types or C-Types:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
Class Types or C-Types:
1 Type 1 Explicit Route
21 ROUTE_RECORD
Class Types or C-Types:
1 Type 1 Route Record
22 HELLO
Class Types or C-Types:
1 Request
2 Acknowledgment
207 SESSION_ATTRIBUTE
Class Types or C-Types:
1 LSP_TUNNEL_RA
7 LSP Tunnel
7.3. Error Codes and Globally-Defined Error Value Sub-Codes
The following list extends the basic list of Error Codes and Values
that are defined in [RFC2205].
Error Code Meaning
24 Routing Problem
This Error Code has the following globally-defined Error
Value sub-codes:
1 Bad EXPLICIT_ROUTE object
2 Bad strict node
3 Bad loose node
4 Bad initial subobject
5 No route available toward
destination
6 Unacceptable label value
7 RRO indicated routing loops
8 MPLS being negotiated, but a
non-RSVP-capable router stands
in the path
9 MPLS label allocation failure
10 Unsupported L3PID
25 Notify Error
This Error Code has the following globally-defined Error
Value sub-codes:
1 RRO too large for MTU
2 RRO Notification
3 Tunnel locally repaired
7.4. Subobject Definitions
Subobjects of the EXPLICIT_ROUTE object with C-Type 1:
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
Subobjects of the RECORD_ROUTE object with C-Type 1:
1 IPv4 address
2 IPv6 address
3 Label
8. Intellectual Property Considerations 8. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
9. Acknowledgments 9. Acknowledgments
skipping to change at page 59, line 26 skipping to change at page 62, line 26
thank the authors of those drafts. They are Steven Blake, Bruce thank the authors of those drafts. They are Steven Blake, Bruce
Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun
Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex
Mondrus for their comments on this draft. Mondrus for their comments on this draft.
10. References 10. References
[1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- [1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205, September 1997. Version 1, Functional Specification", RFC 2205, September 1997.
[2] Rosen, E. et al., "Multiprotocol Label Switching Architeture", [2] Rosen, E. et al., "Multiprotocol Label Switching Architecture",
Internet Draft, draft-ietf-mpls-arch-06.txt, August 1999. RFC 3031, January 2001.
[3] Awduche, D. et al., "Requirements for Traffic Engineering over [3] Awduche, D. et al., "Requirements for Traffic Engineering over
MPLS", RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[4] Wroclawski, J., "Specification of the Controlled-Load Network [4] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997. Element Service", RFC 2211, September 1997.
[5] Rosen, E. et al., "MPLS Label Stack Encoding", Internet Draft, [5] Rosen, E. et al., "MPLS Label Stack Encoding", RFC 3032,
draft-ietf-mpls-label-encaps-07.txt, September 1999. January 2001.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[7] Almquist, P., "Type of Service in the Internet Protocol Suite", [7] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992. RFC 1349, July 1992.
[8] Nichols, K. et al., "Definition of the Differentiated Services [8] Nichols, K. et al., "Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
skipping to change at page 60, line 26 skipping to change at page 63, line 26
[13] Mogul, J. & Deering, S., "Path MTU Discovery", RFC 1191, [13] Mogul, J. & Deering, S., "Path MTU Discovery", RFC 1191,
November 1990. November 1990.
[14] Conta, A. & Deering, S., "Internet Control Message Protocol [14] Conta, A. & Deering, S., "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463,
December 1998. December 1998.
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[16] Bernet, Y. et al., "Specification of the Null Service Type",
RFC 2997, November 2000.
11. Authors' Addresses 11. Authors' Addresses
Daniel O. Awduche Daniel O. Awduche
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615 7926 Jones Branch Drive, Suite 615
McLean, VA 22102 McLean, VA 22102
Voice: +1 703 847 7350 Voice: +1 703 847 7350
Email: awduche@movaz.com Email: awduche@movaz.com
Lou Berger Lou Berger
 End of changes. 

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