draft-ietf-mpls-rsvp-lsp-tunnel-06.txt   draft-ietf-mpls-rsvp-lsp-tunnel-07.txt 
Network Working Group Daniel O. Awduche Network Working Group Daniel O. Awduche
Internet Draft UUNET (MCI Worldcom), Inc. Internet Draft UUNET (MCI Worldcom), Inc.
Expiration Date: January 2001 Expiration Date: February 2001
Lou Berger Lou Berger
LabN Consulting, LLC LabN Consulting, LLC
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.
July 2000 August 2000
RSVP-TE: Extensions to RSVP for LSP Tunnels RSVP-TE: Extensions to RSVP for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-tunnel-06.txt draft-ietf-mpls-rsvp-lsp-tunnel-07.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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the current status of any Internet-Draft, please check the To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html. Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the use of RSVP, including all the necessary This document describes the use of RSVP, including all the necessary
extensions, to establish label-switched paths (LSPs) in MPLS. Since extensions, to establish label-switched paths (LSPs) in MPLS. Since
the flow along an LSP is completely identified by the label applied the flow along an LSP is completely identified by the label applied
at the ingress node of the path, these paths may be treated as at the ingress node of the path, these paths may be treated as
skipping to change at page 3, line 44 skipping to change at page 3, line 44
4.3.1 Applicability .......................................... 26 4.3.1 Applicability .......................................... 26
4.3.2 Semantics of the Explicit Route Object ................. 26 4.3.2 Semantics of the Explicit Route Object ................. 26
4.3.3 Subobjects ............................................. 27 4.3.3 Subobjects ............................................. 27
4.3.4 Processing of the Explicit Route Object ................ 30 4.3.4 Processing of the Explicit Route Object ................ 30
4.3.5 Loops .................................................. 32 4.3.5 Loops .................................................. 32
4.3.6 Forward Compatibility .................................. 32 4.3.6 Forward Compatibility .................................. 32
4.3.7 Non-support of the Explicit Route Object ............... 32 4.3.7 Non-support of the Explicit Route Object ............... 32
4.4 Record Route Object .................................... 33 4.4 Record Route Object .................................... 33
4.4.1 Subobjects ............................................. 33 4.4.1 Subobjects ............................................. 33
4.4.2 Applicability .......................................... 37 4.4.2 Applicability .......................................... 37
4.4.3 Handling RRO ........................................... 37 4.4.3 Processing RRO ......................................... 37
4.5 Processing RRO ......................................... 38 4.4.4 Loop Detection ......................................... 39
4.5.1 Loop Detection ......................................... 39 4.4.5 Forward Compatibility .................................. 39
4.5.2 Forward Compatibility .................................. 39 4.4.6 Non-support of RRO ..................................... 40
4.5.3 Non-support of RRO ..................................... 40 4.5 Error Codes for ERO and RRO ............................ 40
4.6 Error Codes for ERO and RRO ............................ 40 4.6 Session, Sender Template, and Filter Spec Objects ...... 41
4.7 Session, Sender Template, and Filter Spec Objects ...... 41 4.6.1 Session Object ......................................... 41
4.7.1 Session Object ......................................... 41 4.6.2 Sender Template Object ................................. 43
4.7.2 Sender Template Object ................................. 43 4.6.3 Filter Specification Object ............................ 44
4.7.3 Filter Specification Object ............................ 44 4.6.4 Reroute and Bandwidth Increase Procedure ............... 45
4.7.4 Reroute and Bandwidth Increase Procedure ............... 45 4.7 Session Attribute Object ............................... 46
4.8 Session Attribute Object ............................... 46 4.7.1 Format without resource affinities ..................... 46
4.8.1 Format without resource affinities ..................... 46 4.7.2 Format with resource affinities ........................ 48
4.8.2 Format with resource affinities ........................ 48 4.7.3 Procedures applying to both C-Types .................... 49
4.8.3 Procedures applying to both C-Types .................... 49 4.7.4 Resource Affinity Procedures .......................... 51
4.8.4 Resource Affinity Procedures .......................... 51 4.8 Tspec and Flowspec Object for CoS Service ............. 52
4.9 Tspec and Flowspec Object for Class-of-Service Service... 52
5 Hello Extension ........................................ 54 5 Hello Extension ........................................ 54
5.1 Hello Message Format ................................... 55 5.1 Hello Message Format ................................... 55
5.2 HELLO Object formats ................................... 55 5.2 HELLO Object formats ................................... 55
5.2.1 HELLO REQUEST object ................................... 55 5.2.1 HELLO REQUEST object ................................... 55
5.2.2 HELLO ACK object ....................................... 56 5.2.2 HELLO ACK object ....................................... 56
5.3 Hello Message Usage .................................... 56 5.3 Hello Message Usage .................................... 56
5.4 Multi-Link Considerations .............................. 58 5.4 Multi-Link Considerations .............................. 58
5.5 Compatibility .......................................... 58 5.5 Compatibility .......................................... 58
6 Security Considerations ................................ 59 6 Security Considerations ................................ 59
7 IANA Considerations .................................... 59 7 IANA Considerations .................................... 59
skipping to change at page 6, line 39 skipping to change at page 6, line 39
Tunnel". When labels are associated with traffic flows, it becomes Tunnel". When labels are associated with traffic flows, it becomes
possible for a router to identify the appropriate reservation state possible for a router to identify the appropriate reservation state
for a packet based on the packet's label value. for a packet based on the packet's label value.
The signaling protocol model uses downstream-on-demand label The signaling protocol model uses downstream-on-demand label
distribution. A request to bind labels to a specific LSP tunnel is distribution. A request to bind labels to a specific LSP tunnel is
initiated by an ingress node through the RSVP Path message. For this initiated by an ingress node through the RSVP Path message. For this
purpose, the RSVP Path message is augmented with a LABEL_REQUEST purpose, the RSVP Path message is augmented with a LABEL_REQUEST
object. Labels are allocated downstream and distributed (propagated object. Labels are allocated downstream and distributed (propagated
upstream) by means of the RSVP Resv message. For this purpose, the upstream) by means of the RSVP Resv message. For this purpose, the
RSVP Resv message is extended with a special LABEL object. Label RSVP Resv message is extended with a special LABEL object. The
stacking is also supported. The procedures for label allocation, procedures for label allocation, distribution, binding, and stacking
distribution, binding, and stacking are described in subsequent are described in subsequent sections of this document.
sections of this document.
The signaling protocol model also supports explicit routing The signaling protocol model also supports explicit routing
capability. This is accomplished by incorporating a simple capability. This is accomplished by incorporating a simple
EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE
object encapsulates a concatenation of hops which constitutes the object encapsulates a concatenation of hops which constitutes the
explicitly routed path. Using this object, the paths taken by label- explicitly routed path. Using this object, the paths taken by label-
switched RSVP-MPLS flows can be pre-determined, independent of switched RSVP-MPLS flows can be pre-determined, independent of
conventional IP routing. The explicitly routed path can be conventional IP routing. The explicitly routed path can be
administratively specified, or automatically computed by a suitable administratively specified, or automatically computed by a suitable
entity based on QoS and policy requirements, taking into entity based on QoS and policy requirements, taking into
skipping to change at page 8, line 33 skipping to change at page 8, line 30
LSP LSP
A Label Switched Path A Label Switched Path
LSP Tunnel LSP Tunnel
An LSP which is used to tunnel below normal IP routing and/or An LSP which is used to tunnel below normal IP routing and/or
filtering mechanisms. filtering mechanisms.
Traffic Engineered Tunnel (TE Tunnel) Traffic Engineered Tunnel (TE Tunnel)
An set of one or more LSP Tunnels which carries a traffic A set of one or more LSP Tunnels which carries a traffic trunk.
trunk.
Traffic Trunk Traffic Trunk
An set of flows aggregated by their service class and then A set of flows aggregated by their service class and then
placed on an LSP or set of LSPs called a traffic engineered placed on an LSP or set of LSPs called a traffic engineered
tunnel. For further discussion see [3]. tunnel. For further discussion see [3].
2. Overview 2. Overview
2.1. LSP Tunnels and Traffic Engineered Tunnels 2.1. LSP Tunnels and Traffic Engineered Tunnels
According to [1], "RSVP defines a 'session' to be a data flow with a According to [1], "RSVP defines a 'session' to be a data flow with a
particular destination and transport-layer protocol." However, when particular destination and transport-layer protocol." However, when
RSVP and MPLS are combined, a flow or session can be defined with RSVP and MPLS are combined, a flow or session can be defined with
greater flexibility and generality. The ingress node of an LSP can greater flexibility and generality. The ingress node of an LSP can
use a variety of means to determine which packets are assigned a use a variety of means to determine which packets are assigned a
particular label. Once a label is assigned to a set of packets, the particular label. Once a label is assigned to a set of packets, the
label effectively defines the "flow" through the LSP. We refer to label effectively defines the "flow" through the LSP. We refer to
such an LSP as an "LSP tunnel" because the traffic through it is such an LSP as an "LSP tunnel" because the traffic through it is
opaque to intermediate nodes along the label switched path. opaque to intermediate nodes along the label switched path.
New RSVP SESSION, SENDER, and FILTER_SPEC objects, called New RSVP SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects, called
LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 have been defined to support the LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 have been defined to support the
LSP tunnel feature. The semantics of these objects, from the LSP tunnel feature. The semantics of these objects, from the
perspective of a node along the label switched path, is that traffic perspective of a node along the label switched path, is that traffic
belonging to the LSP tunnel is identified solely on the basis of belonging to the LSP tunnel is identified solely on the basis of
packets arriving from the PHOP or "previous hop" (see [1]) with the packets arriving from the PHOP or "previous hop" (see [1]) with the
particular label value(s) assigned by this node to upstream senders particular label value(s) assigned by this node to upstream senders
to the session. In fact, the IPv4(v6) that appears in the object to the session. In fact, the IPv4(v6) that appears in the object
name only denotes that the destination address is an IPv4(v6) name only denotes that the destination address is an IPv4(v6)
address. When we refer to these objects generically, we use the address. When we refer to these objects generically, we use the
qualifier LSP_TUNNEL. qualifier LSP_TUNNEL.
In some applications it is useful to associate sets of LSP tunnels. In some applications it is useful to associate sets of LSP tunnels.
This can be useful during reroute operations or to spread a traffic This can be useful during reroute operations or to spread a traffic
trunk over multiple paths. In the traffic engineering application trunk over multiple paths. In the traffic engineering application
such sets are called traffic engineered tunnels (TE tunnels). To such sets are called traffic engineered tunnels (TE tunnels). To
enable the identification and association of such LSP tunnels, two enable the identification and association of such LSP tunnels, two
identifiers are carried. A tunnel ID is part of the SESSION object. identifiers are carried. A tunnel ID is part of the SESSION object.
The SESSION object uniquely defines a traffic engineered tunnel. The The SESSION object uniquely defines a traffic engineered tunnel. The
SENDER and FILTER_SPEC objects carry an LSP ID. The SENDER (or SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The
FILTER_SPEC) object together with the SESSION object uniquely SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION
identifies an LSP tunnel object uniquely identifies an LSP tunnel
2.2. Operation of LSP Tunnels 2.2. Operation of LSP Tunnels
This section summarizes some of the features supported by RSVP as This section summarizes some of the features supported by RSVP as
extended by this document related to the operation of LSP tunnels. extended by this document related to the operation of LSP tunnels.
These include: (1) the capability to establish LSP tunnels with or These include: (1) the capability to establish LSP tunnels with or
without QoS requirements, (2) the capability to dynamically reroute without QoS requirements, (2) the capability to dynamically reroute
an established LSP tunnel, (3) the capability to observe the actual an established LSP tunnel, (3) the capability to observe the actual
route traversed by an established LSP tunnel, (4) the capability to route traversed by an established LSP tunnel, (4) the capability to
identify and diagnose LSP tunnels, (5) the capability to preempt an identify and diagnose LSP tunnels, (5) the capability to preempt an
skipping to change at page 10, line 29 skipping to change at page 10, line 29
identifies the higher layer protocol as MPLS. identifies the higher layer protocol as MPLS.
If the sender node has knowledge of a route that has high likelihood If the sender node has knowledge of a route that has high likelihood
of meeting the tunnel's QoS requirements, or that makes efficient use of meeting the tunnel's QoS requirements, or that makes efficient use
of network resources, or that satisfies some policy criteria, the of network resources, or that satisfies some policy criteria, the
node can decide to use the route for some or all of its sessions. To node can decide to use the route for some or all of its sessions. To
do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP
Path message. The EXPLICIT_ROUTE object specifies the route as a Path message. The EXPLICIT_ROUTE object specifies the route as a
sequence of abstract nodes. sequence of abstract nodes.
If, after a session has been successfully established and the sender If, after a session has been successfully established, the sender
node discovers a better route, the sender can dynamically reroute the node discovers a better route, the sender can dynamically reroute the
session by simply changing the EXPLICIT_ROUTE object. If problems session by simply changing the EXPLICIT_ROUTE object. If problems
are encountered with an EXPLICIT_ROUTE object, either because it are encountered with an EXPLICIT_ROUTE object, either because it
causes a routing loop or because some intermediate routers do not causes a routing loop or because some intermediate routers do not
support it, the sender node is notified. support it, the sender node is notified.
By adding a RECORD_ROUTE object to the Path message, the sender node By adding a RECORD_ROUTE object to the Path message, the sender node
can receive information about the actual route that the LSP tunnel can receive information about the actual route that the LSP tunnel
traverses. The sender node can also use this object to request traverses. The sender node can also use this object to request
notification from the network concerning changes to the routing path. notification from the network concerning changes to the routing path.
The RECORD_ROUTE object is analogous to a path vector, and hence can The RECORD_ROUTE object is analogous to a path vector, and hence can
be used for loop detection. be used for loop detection.
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.
The setup and hold priorities may be used along with SENDER_TSPEC and Routers along the path may use the setup and hold priorities along
any POLICY_DATA objects contained in Path messages as input to their with SENDER_TSPEC and any POLICY_DATA objects contained in Path
policy control. For instance, in the traffic engineering messages as input to policy control. For instance, in the traffic
application, it is very useful to use the Path message as a means of engineering application, it is very useful to use the Path message as
verifying that bandwidth exists at a particular priority along an a means of verifying that bandwidth exists at a particular priority
entire path before pre-empting any lower priority reservations. If a along an entire path before pre-empting any lower priority
Path message is allowed to progress when there are insufficient reservations. If a Path message is allowed to progress when there
resources, the there is a danger that lower priority reservations are insufficient resources, the there is a danger that lower priority
downstream of this point will unnecessarily be pre-empted in a futile reservations downstream of this point will unnecessarily be pre-
attempt to service this request. empted 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 8 skipping to change at page 12, line 8
shorthand for the Filter Spec. The node can now update its "Incoming shorthand for the Filter Spec. The node can now update its "Incoming
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 Class-of-Service service, see
Section 4.8. 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.
skipping to change at page 14, line 23 skipping to change at page 14, line 23
failure of a resource along the TE tunnel's established path. Under failure of a resource along the TE tunnel's established path. Under
some policies, it may also be necessary to return the TE tunnel to some policies, it may also be necessary to return the TE tunnel to
its original path when the failed resource becomes re-activated. its original path when the failed resource becomes re-activated.
In general, it is highly desirable not to disrupt traffic, or In general, it is highly desirable not to disrupt traffic, or
adversely impact network operations while TE tunnel rerouting is in adversely impact network operations while TE tunnel rerouting is in
progress. This adaptive and smooth rerouting requirement progress. This adaptive and smooth rerouting requirement
necessitates establishing a new LSP tunnel and transferring traffic necessitates establishing a new LSP tunnel and transferring traffic
from the old LSP tunnel onto it before tearing down the old LSP from the old LSP tunnel onto it before tearing down the old LSP
tunnel. This concept is called "make-before-break." A problem can tunnel. This concept is called "make-before-break." A problem can
arise because the old and new LSP tunnels might compete with other arise because the old and new LSP tunnels might compete with each
for resources on network segments which they have in common. other for resources on network segments which they have in common.
Depending on availability of resources, this competition can cause Depending on availability of resources, this competition can cause
Admission Control to prevent the new LSP tunnel from being Admission Control to prevent the new LSP tunnel from being
established. An advantage of using RSVP to establish LSP tunnels is established. An advantage of using RSVP to establish LSP tunnels is
that it solves this problem very elegantly. that it solves this problem very elegantly.
To support make-before-break in a smooth fashion, it is necessary To support make-before-break in a smooth fashion, it is necessary
that on links that are common to the old and new LSPs, resources used that on links that are common to the old and new LSPs, resources used
by the old LSP tunnel should not be released before traffic is by the old LSP tunnel should not be released before traffic is
transitioned to the new LSP tunnel, and reservations should not be transitioned to the new LSP tunnel, and reservations should not be
counted twice because this might cause Admission Control to reject counted twice because this might cause Admission Control to reject
the new LSP tunnel. the new LSP tunnel.
A similar situation arises when one wants to increase the bandwidth A similar situation can arise when one wants to increase the
of a TE tunnel. The new reservation will be for the full amount bandwidth of a TE tunnel. The new reservation will be for the full
needed, but the actual allocation needed is only the delta between amount needed, but the actual allocation needed is only the delta
the new and old bandwidth. between the new and old bandwidth. If policy is being applied to
PATH messages by intermediate nodes, then a PATH message requesting
too much bandwidth will be rejected. In this situation simply
increasing the bandwidth request without changing the
SENDER_TEMPLATE, could result in a tunnel being torn down, depending
upon local policy.
The combination of the LSP_TUNNEL SESSION object and the SE The combination of the LSP_TUNNEL SESSION object and the SE
reservation style naturally accommodates smooth transitions in reservation style naturally accommodates smooth transitions in
bandwidth and routing. The idea is that the old and new LSP tunnels bandwidth and routing. The idea is that the old and new LSP tunnels
share resources along links which they have in common. The LSP_TUNNEL share resources along links which they have in common. The LSP_TUNNEL
SESSION object is used to narrow the scope of the RSVP session to the SESSION object is used to narrow the scope of the RSVP session to the
particular TE tunnel in question. To uniquely identify a TE tunnel, particular TE tunnel in question. To uniquely identify a TE tunnel,
we use the combination of the destination IP address (an address of we use the combination of the destination IP address (an address of
the node which is the egress of the tunnel), a Tunnel ID, and the the node which is the egress of the tunnel), a Tunnel ID, and the
tunnel ingress node's IP address, which is placed in the Extended tunnel ingress node's IP address, which is placed in the Extended
skipping to change at page 16, line 20 skipping to change at page 16, line 25
by this node. by this node.
2. Let M be the smaller of the "Maximum Initially Labeled IP 2. Let M be the smaller of the "Maximum Initially Labeled IP
Datagram Size" or of (Path MTU - N). Datagram Size" or of (Path MTU - N).
When the size of the datagram (without labels) exceeds the value When the size of the datagram (without labels) exceeds the value
of M, of M,
If the DF bit is not set in the IP header, then If the DF bit is not set in the IP header, then
(a) the datagram must be broken into fragments, each of whose (a) the datagram MUST be broken into fragments, each of whose
size is no greater than the value of the parameter, and size is no greater than M, and
(b) each fragment must be labeled and then forwarded. (b) each fragment MUST be labeled and then forwarded.
If the DF bit is set in the IP header, then If the DF bit is set in the IP header, then
(a) the datagram MUST NOT be forwarded (a) the datagram MUST NOT be forwarded
(b) Create an ICMP Destination Unreachable Message: (b) Create an ICMP Destination Unreachable Message:
i. set its Code field [12] to "Fragmentation Required i. set its Code field [12] to "Fragmentation Required
and DF Set", and DF Set",
ii. set its Next-Hop MTU field [13] to M ii. set its Next-Hop MTU field [13] to M
skipping to change at page 17, line 26 skipping to change at page 17, line 31
SESSION_ATTRIBUTE objects is simply a recommendation. The ordering SESSION_ATTRIBUTE objects is simply a recommendation. The ordering
of these objects is not important, so an implementation MUST be of these objects is not important, so an implementation MUST be
prepared to accept objects in any order. prepared to accept objects in any order.
3.1. Path Message 3.1. Path Message
The format of the Path message is as follows: The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <TIME_VALUES> ] <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <ADSPEC> ]
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
3.2. Resv Message 3.2. Resv Message
The format of the Resv message is as follows: The format of the Resv message is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <TIME_VALUES> ] <TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list> <flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor> | <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FF flow descriptor> <FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
| <FF flow descriptor list> <FF flow descriptor> <LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec> <SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec> | <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
skipping to change at page 19, line 19 skipping to change at page 19, line 33
following discussion, the term "same label" means the identical label following discussion, the term "same label" means the identical label
value drawn from the identical label space. Further, the following value drawn from the identical label space. Further, the following
applies only to unicast sessions. applies only to unicast sessions.
Labels received in Resv messages on different interfaces are always Labels received in Resv messages on different interfaces are always
considered to be different even if the label value is the same. considered to be different even if the label value is the same.
4.1.1.1. Downstream 4.1.1.1. Downstream
The downstream node selects a label to represent the flow. If a The downstream node selects a label to represent the flow. If a
label range has been specified in the label request, the label must label range has been specified in the label request, the label MUST
be drawn from that range. If no label is available the node sends a be drawn from that range. If no label is available the node sends a
PathErr message with an error code of "routing problem" and an error PathErr message with an error code of "routing problem" and an error
value of "label allocation failure". value of "label allocation failure".
If a node receives a Resv message that has assigned the same label If a node receives a Resv message that has assigned the same label
value to multiple senders, then that node MAY also assign the same value to multiple senders, then that node MAY also assign a single
value to those same senders or to any subset of those senders. Note value to those same senders or to any subset of those senders. Note
that if a node intends to police individual senders to a session, it that if a node intends to police individual senders to a session, it
MUST assign unique labels to those senders. MUST assign unique labels to those senders.
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. The M-bit in the LABEL_REQUEST setting a bit in the label request to zero. The M-bit in the
object of C-Type 2, label request with ATM label range, serves this LABEL_REQUEST object of C-Type 2, label request with ATM label range,
purpose. The M-bit SHOULD be set by nodes which are merge capable. serves this purpose. The M-bit SHOULD be set by nodes which are
If for any senders the M-bit is not set, the downstream node MUST merge capable. If for any senders the M-bit is not set, the
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 LABEL object SHOULD be kept in the Reservation
State Block. It is then used in the next Resv refresh event for State Block. It is then used in the next Resv refresh event for
formatting the Resv message. 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.
skipping to change at page 20, line 14 skipping to change at page 20, line 28
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
to the previous hops. to the previous hops.
Several circumstance can lead to an unacceptable label. Several circumstance can lead to an unacceptable label.
1. the node is a merge incapable ATM switch but the downstream node 1. the node is a merge incapable ATM switch but the downstream node
has assigned the same label to two senders has assigned the same label to two senders
2. The implicit null label was assigned, but the node is not 2. The implicit null label was assigned, but the node is not
capable capable of doing a penultimate pop for the associated L3PID
of doing a penultimate pop for the associated L3PID
3. The assigned label is outside the requested label range 3. The assigned label is outside the requested label range
In any of these events the node send a ResvErr message with an error In any of these events the node send a ResvErr message with an error
code of "routing problem" and an error value of "unacceptable label code of "routing problem" and an error value of "unacceptable label
value". value".
4.1.2. Non-support of the Label Object 4.1.2. Non-support of the Label Object
Under normal circumstances, a node should never receive a LABEL Under normal circumstances, a node should never receive a LABEL
skipping to change at page 22, line 14 skipping to change at page 22, line 14
This field is reserved. It MUST be set to zero on transmis- This field is reserved. It MUST be set to zero on transmis-
sion and MUST be ignored on receipt. sion and MUST be ignored on receipt.
L3PID L3PID
an identifier of the layer 3 protocol using this path. an identifier of the layer 3 protocol using this path.
Standard Ethertype values are used. Standard Ethertype values are used.
M M
Setting this bit to one indicates that the node is not capable Setting this bit to one indicates that the node is capable
of merging in the data plane of merging in the data plane
Minimum VPI (12 bits) Minimum VPI (12 bits)
This 12 bit field specifies the lower bound of a block of This 12 bit field specifies the lower bound of a block of
Virtual Path Identifiers that is supported on the originating Virtual Path Identifiers that is supported on the originating
switch. If the VPI is less than 12-bits it MUST be right switch. If the VPI is less than 12-bits it MUST be right
justified in this field and preceding bits MUST be set to zero. justified in this field and preceding bits MUST be set to zero.
Minimum VCI (16 bits) Minimum VCI (16 bits)
skipping to change at page 24, line 38 skipping to change at page 24, line 38
correctly process a LABEL object in the corresponding Resv messages. correctly process a LABEL object in the corresponding Resv messages.
A node that recognizes a LABEL_REQUEST object, but that is unable to A node that recognizes a LABEL_REQUEST object, but that is unable to
support it (possibly because of a failure to allocate labels) SHOULD support it (possibly because of a failure to allocate labels) SHOULD
send a PathErr with the error code "Routing problem" and the error send a PathErr with the error code "Routing problem" and the error
value "MPLS label allocation failure." This includes the case where value "MPLS label allocation failure." This includes the case where
a label range has been specified and a label cannot be allocated from a label range has been specified and a label cannot be allocated from
that range. that range.
A node which receives and forwards a Path message each with a A node which receives and forwards a Path message each with a
LABEL_REQUEST object, must copy the L3PID from the received LABEL_REQUEST object, MUST copy the L3PID from the received
LABEL_REQUEST object to the forwarded LABEL_REQUEST object. LABEL_REQUEST object to the forwarded LABEL_REQUEST object.
If the receiver cannot support the protocol L3PID, it SHOULD send a If the receiver cannot support the protocol L3PID, it SHOULD send a
PathErr with the error code "Routing problem" and the error value PathErr with the error code "Routing problem" and the error value
"Unsupported L3PID." This causes the RSVP session to fail. "Unsupported L3PID." This causes the RSVP session to fail.
4.2.5. Non-support of the Label Request Object 4.2.5. Non-support of the Label Request Object
An RSVP router that does not recognize the LABEL_REQUEST object sends An RSVP router that does not recognize the LABEL_REQUEST object sends
a PathErr with the error code "Unknown object class" toward the a PathErr with the error code "Unknown object class" toward the
skipping to change at page 35, line 11 skipping to change at page 35, line 11
Prefix length Prefix length
32 32
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_ATTRIBUITE 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 a 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.2. Subobject 2: IPv6 address 4.4.1.2. Subobject 2: IPv6 address
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 | IPv6 address (16 bytes) | | Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
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_ATTRIBUITE object of the cooresponding Path SESSION_ATTRIBUTE object of the cooresponding Path
nessage. nessage.
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 a 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 0x03, 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 |
skipping to change at page 37, line 35 skipping to change at page 37, line 35
hop about RSVP sessions, providing valuable information to the sender hop about RSVP sessions, providing valuable information to the sender
or receiver. Any path change (due to network topology changes) will or receiver. Any path change (due to network topology changes) will
be reported. be reported.
Third, RRO syntax is designed so that, with minor changes, the whole Third, RRO syntax is designed so that, with minor changes, the whole
object can be used as input to the EXPLICIT_ROUTE object. This is object can be used as input to the EXPLICIT_ROUTE object. This is
useful if the sender receives RRO from the receiver in a Resv useful if the sender receives RRO from the receiver in a Resv
message, applies it to EXPLICIT_ROUTE object in the next Path message message, applies it to EXPLICIT_ROUTE object in the next Path message
in order to "pin down session path". in order to "pin down session path".
4.4.3. Handling RRO 4.4.3. Processing RRO
Typically, a node initiates an RSVP session by adding the RRO to the Typically, a node initiates an RSVP session by adding the RRO to the
Path message. The initial RRO contains only one subobject - the Path message. The initial RRO contains only one subobject - the
sender's IP addresses. If the node also desires label recording, it sender's IP addresses. If the node also desires label recording, it
sets the Label_Recording flag in the SESSION_ATTRIBUTE object. sets the Label_Recording flag in the SESSION_ATTRIBUTE object.
When a Path message containing an RRO is received by an intermediate When a Path message containing an RRO is received by an intermediate
router, the router stores a copy of it in the Path State Block. The router, the router stores a copy of it in the Path State Block. The
RRO is then used in the next Path refresh event for formatting Path RRO is then used in the next Path refresh event for formatting Path
messages. When a new Path message is to be sent, the router adds a messages. When a new Path message is to be sent, the router adds a
new subobject to the RRO and appends the resulting RRO to the Path new subobject to the RRO and appends the resulting RRO to the Path
message before transmission. message before transmission.
The newly added subobject MUST be this router's IP address. The The newly added subobject MUST be this router's IP address. The
address to be added SHOULD be the interface address of the outgoing address to be added SHOULD be the interface address of the outgoing
Path messages. If there are multiple addresses to choose from, the Path messages. If there are multiple addresses to choose from, the
decision is a local matter. However, it is RECOMMENDED that the same decision is a local matter. However, it is RECOMMENDED that the same
address be chosen consistently. address be chosen consistently.
4.5. Processing RRO
When the Label_Recording flag is set in the SESSION_ATTRIBUTE object, When the Label_Recording flag is set in the SESSION_ATTRIBUTE object,
nodes doing route recording SHOULD include a Label Record subobject. nodes doing route recording SHOULD include a Label Record subobject.
If the node is using a global label space, then it SHOULD set the If the node is using a global label space, then it SHOULD set the
Global Label flag. Global Label flag.
The Label Record subobject is pushed onto the RECORD_ROUTE object The Label Record subobject is pushed onto the RECORD_ROUTE object
prior to pushing on the node's IP address. A node MUST NOT push on a prior to pushing on the node's IP address. A node MUST NOT push on a
Label Record subobject without also pushing on an IPv4 or IPv6 Label Record subobject without also pushing on an IPv4 or IPv6
subobject. subobject.
Note that on receipt of the initial Path message, a node is unlikely
to have a label to include. Once a label is obtained, the node
SHOULD include the label in the RRO in the next Path refresh event.
If the newly added subobject causes the RRO to be too big to fit in a If the newly added subobject causes the RRO to be too big to fit in a
Path (or Resv) message, the RRO object SHALL be dropped from the Path (or Resv) message, the RRO object SHALL be dropped from the
message and message processing continues as normal. A PathErr (or message and message processing continues as normal. A PathErr (or
ResvErr) message SHOULD be sent back to the sender (or receiver). An ResvErr) message SHOULD be sent back to the sender (or receiver). An
error code of "Notify" and an error value of "RRO too large for MTU" error code of "Notify" and an error value of "RRO too large for MTU"
is used. If the receiver receives such a ResvErr, it SHOULD send a is used. If the receiver receives such a ResvErr, it SHOULD send a
PathErr message with error code of "Notify" and an error value of PathErr message with error code of "Notify" and an error value of
"RRO notification". "RRO notification".
A sender receiving either of these error values should remove the RRO A sender receiving either of these error values SHOULD remove the RRO
from the Path message. from the Path message.
Nodes should resend the above PathErr or ResvErr message each n Nodes SHOULD resend the above PathErr or ResvErr message each n
seconds where n is the greater of 15 and the refresh interval for the seconds where n is the greater of 15 and the refresh interval for the
associated Path or RESV message. The node may apply limits and/or associated Path or RESV message. The node MAY apply limits and/or
back-off timers to limit the number of messages sent. back-off timers to limit the number of messages sent.
An RSVP router can decide to send Path messages before its refresh An RSVP router can decide to send Path messages before its refresh
time if the RRO in the next Path message is different from the time if the RRO in the next Path message is different from the
previous one. This can happen if the contents of the RRO received previous one. This can happen if the contents of the RRO received
from the previous hop router changes or if this RRO is newly added to from the previous hop router changes or if this RRO is newly added to
(or deleted from) the Path message. (or deleted from) the Path message.
When the destination node of an RSVP session receives a Path message When the destination node of an RSVP session receives a Path message
with an RRO, this indicates that the sender node needs route with an RRO, this indicates that the sender node needs route
skipping to change at page 39, line 14 skipping to change at page 39, line 14
Note that each node along the path will now have the complete route Note that each node along the path will now have the complete route
from source to destination. The Path RRO will have the route from from source to destination. The Path RRO will have the route from
the source to this node; the Resv RRO will have the route from this the source to this node; the Resv RRO will have the route from this
node to the destination. This is useful for network management. node to the destination. This is useful for network management.
A received Path message without an RRO indicates that the sender node A received Path message without an RRO indicates that the sender node
no longer needs route recording. Subsequent Resv messages SHALL NOT no longer needs route recording. Subsequent Resv messages SHALL NOT
contain an RRO. contain an RRO.
4.5.1. Loop Detection 4.4.4. Loop Detection
As part of processing an incoming RRO, an intermediate router looks As part of processing an incoming RRO, an intermediate router looks
into all subobjects contained within the RRO. If the router into all subobjects contained within the RRO. If the router
determines that it is already in the list, a forwarding loop exists. determines that it is already in the list, a forwarding loop exists.
An RSVP session is loop-free if downstream nodes receive Path An RSVP session is loop-free if downstream nodes receive Path
messages or upstream nodes receive Resv messages with no routing messages or upstream nodes receive Resv messages with no routing
loops detected in the contained RRO. loops detected in the contained RRO.
There are two broad classifications of forwarding loops. The first There are two broad classifications of forwarding loops. The first
skipping to change at page 39, line 44 skipping to change at page 39, line 44
For Path messages containing a forwarding loop, the router builds and For Path messages containing a forwarding loop, the router builds and
sends a "Routing problem" PathErr message, with the error value "loop sends a "Routing problem" PathErr message, with the error value "loop
detected," and drops the Path message. Until the loop is eliminated, detected," and drops the Path message. Until the loop is eliminated,
this session is not suitable for forwarding data packets. How the this session is not suitable for forwarding data packets. How the
loop eliminated is beyond the scope of this document. loop eliminated is beyond the scope of this document.
For Resv messages containing a forwarding loop, the router simply For Resv messages containing a forwarding loop, the router simply
drops the message. Resv messages should not loop if Path messages do drops the message. Resv messages should not loop if Path messages do
not loop. not loop.
4.5.2. Forward Compatibility 4.4.5. Forward Compatibility
New subobjects may be defined for the RRO. When processing an RRO, New subobjects may be defined for the RRO. When processing an RRO,
unrecognized subobjects should be ignored and passed on. When unrecognized subobjects SHOULD be ignored and passed on. When
processing an RRO for loop detection, a node SHOULD parse over any processing an RRO for loop detection, a node SHOULD parse over any
unrecognized objects. Loop detection works by detecting subobjects unrecognized objects. Loop detection works by detecting subobjects
which were inserted by the node itself on an earlier pass of the which were inserted by the node itself on an earlier pass of the
object. This ensures that the subobjects necessary to loop detection object. This ensures that the subobjects necessary for loop detection
are always understood. are always understood.
4.5.3. Non-support of RRO 4.4.6. Non-support of RRO
The RRO object is to be used only when all routers along the path The RRO object is to be used only when all routers along the path
support RSVP and the RRO object. The RRO object is assigned a class support RSVP and the RRO object. The RRO object is assigned a class
value of the form 0bbbbbbb. RSVP routers that do not support the value of the form 0bbbbbbb. RSVP routers that do not support the
object will therefore respond with an "Unknown Object Class" error. object will therefore respond with an "Unknown Object Class" error.
4.6. Error Codes for ERO and RRO 4.5. Error Codes for ERO and RRO
In the processing described above, certain errors must be reported as In the processing described above, certain errors must be reported as
either a "Routing Problem" or "Notify". The value of the "Routing either a "Routing Problem" or "Notify". The value of the "Routing
Problem" error code is 24; the value of the "Notify" error code is Problem" error code is 24; the value of the "Notify" error code is
25. 25.
The following defines error values for the Routing Problem Error The following defines error values for the Routing Problem Error
Code: Code:
Value Error: Value Error:
skipping to change at page 41, line 10 skipping to change at page 41, line 10
9 MPLS label allocation failure 9 MPLS label allocation failure
10 Unsupported L3PID 10 Unsupported L3PID
For the Notify Error Code, the 16 bits of the Error Value field are: For the Notify Error Code, the 16 bits of the Error Value field are:
ss00 cccc cccc cccc ss00 cccc cccc cccc
The high order bits are as defined under Error Code 1. (See [1]). The high order bits are as defined under Error Code 1. (See [1]).
When ss = 00, the following subcode is defined: When ss = 00, the following subcodes are defined:
1 RRO too large for MTU 1 RRO too large for MTU
2 RRO notification 2 RRO notification
4.7. Session, Sender Template, and Filter Spec Objects 4.6. Session, Sender Template, and Filter Spec Objects
New C-Types are defined for the SESSION, SENDER_TEMPLATE and New C-Types are defined for the SESSION, SENDER_TEMPLATE and
FILTER_SPEC objects. FILTER_SPEC objects.
The LSP_TUNNEL objects have the following format: The LSP_TUNNEL objects have the following format:
4.7.1. Session Object 4.6.1. Session Object
4.7.1.1. LSP_TUNNEL_IPv4 Session Object 4.6.1.1. LSP_TUNNEL_IPv4 Session Object
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7 Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID | | MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 42, line 13 skipping to change at page 42, line 13
over the life of the tunnel. over the life of the tunnel.
Extended Tunnel ID Extended Tunnel ID
A 32-bit identifier used in the SESSION that remains constant A 32-bit identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros. over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv4 address here as a ingress-egress pair may place their IPv4 address here as a
globally unique identifier. globally unique identifier.
4.7.1.2. LSP_TUNNEL_IPv6 Session Object 4.6.1.2. LSP_TUNNEL_IPv6 Session Object
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8 Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 tunnel end point address | | IPv6 tunnel end point address |
+ + + +
skipping to change at page 43, line 13 skipping to change at page 43, line 13
over the life of the tunnel. over the life of the tunnel.
Extended Tunnel ID Extended Tunnel ID
A 16-byte identifier used in the SESSION that remains constant A 16-byte identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros. over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv6 address here as a ingress-egress pair may place their IPv6 address here as a
globally unique identifier. globally unique identifier.
4.7.2. Sender Template Object 4.6.2. Sender Template Object
4.7.2.1. LSP_TUNNEL_IPv4 Sender Template Object 4.6.2.1. LSP_TUNNEL_IPv4 Sender Template Object
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7 Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID | | MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 44, line 5 skipping to change at page 44, line 5
IPv4 tunnel sender address IPv4 tunnel sender address
IPv4 address for a sender node IPv4 address for a sender node
LSP ID LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the A 16-bit identifier used in the SENDER_TEMPLATE and the
FILTER_SPEC that can be changed to allow a sender to share FILTER_SPEC that can be changed to allow a sender to share
resources with itself. resources with itself.
4.7.2.2. LSP_TUNNEL_IPv6 Sender Template Object 4.6.2.2. LSP_TUNNEL_IPv6 Sender Template Object
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8 Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
+ + + +
skipping to change at page 44, line 33 skipping to change at page 44, line 33
IPv6 tunnel sender address IPv6 tunnel sender address
IPv6 address for a sender node IPv6 address for a sender node
LSP ID LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the A 16-bit identifier used in the SENDER_TEMPLATE and the
FILTER_SPEC that can be changed to allow a sender to share FILTER_SPEC that can be changed to allow a sender to share
resources with itself. resources with itself.
4.7.3. Filter Specification Object 4.6.3. Filter Specification Object
4.7.3.1. LSP_TUNNEL_IPv4 Filter Specification Object 4.6.3.1. LSP_TUNNEL_IPv4 Filter Specification Object
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7 Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7
The format of the LSP_TUNNEL_IPv4 FILTER_SPEC object is identical to The format of the LSP_TUNNEL_IPv4 FILTER_SPEC object is identical to
the LSP_TUNNEL_IPv4 SENDER_TEMPLATE object. the LSP_TUNNEL_IPv4 SENDER_TEMPLATE object.
4.7.3.2. LSP_TUNNEL_IPv6 Filter Specification Object 4.6.3.2. LSP_TUNNEL_IPv6 Filter Specification Object
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8 Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8
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.7.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 a
LSP_ID. Tunnel setup then proceeds according to the normal procedure. 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
skipping to change at page 46, line 5 skipping to change at page 46, line 5
<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.)
When the ingress node receives the Resv Message(s), it may begin When the ingress node receives the Resv Message(s), it may begin
using the new route. It SHOULD send a PathTear message for the old using the new route. It SHOULD send a PathTear message for the old
route. route.
4.8. Session Attribute Object 4.7. Session Attribute Object
The Session Attribute Class is 207. Two C_Types are defined, The Session Attribute Class is 207. Two C_Types are defined,
LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The
LSP_TUNNEL_RA C-Type includes all the same fields as the LSP_TUNNEL LSP_TUNNEL_RA C-Type includes all the same fields as the LSP_TUNNEL
C-Type. Additionally it carries resource affinity information. The C-Type. Additionally it carries resource affinity information. The
formats are as follows: formats are as follows:
4.8.1. Format without resource affinities 4.7.1. Format without resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7 SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length | | Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Session Name (NULL padded display string) // // Session Name (NULL padded display string) //
skipping to change at page 47, line 7 skipping to change at page 47, line 7
Holding Priority Holding Priority
The priority of the session with respect to holding resources, The priority of the session with respect to holding resources,
in the range of 0 to 7. The value 0 is the highest priority. in the range of 0 to 7. The value 0 is the highest priority.
Holding Priority is used in deciding whether this session can Holding Priority is used in deciding whether this session can
be preempted by another session. be preempted by another session.
Flags Flags
0x01 Local protection 0x01 Local protection desired
This flag permits transit routers to use a local repair This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute downstream link or node, a transit router can reroute
traffic for fast service restoration. traffic for fast service restoration.
0x02 Label recording desired 0x02 Label recording desired
This flag indicates that label information should be This flag indicates that label information should be
included when doing a route record. included when doing a route record.
0x04 Ingress node may reroute 0x04 SE Style desired
This flag indicates that the tunnel ingress node may This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down. choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when A tunnel egress node SHOULD use the SE Style when
responding with a Resv message. responding with a Resv message.
Name Length Name Length
The length of the display string before padding, in bytes. The length of the display string before padding, in bytes.
Session Name Session Name
A null padded string of characters. A null padded string of characters.
4.8.2. Format with resource affinities 4.7.2. Format with resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1 SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any | | Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any | | Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 49, line 14 skipping to change at page 49, line 14
Holding Priority Holding Priority
The priority of the session with respect to holding resources, The priority of the session with respect to holding resources,
in the range of 0 to 7. The value 0 is the highest priority. in the range of 0 to 7. The value 0 is the highest priority.
Holding Priority is used in deciding whether this session can Holding Priority is used in deciding whether this session can
be preempted by another session. be preempted by another session.
Flags Flags
0x01 Local protection 0x01 Local protection desired
This flag permits transit routers to use a local repair This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute downstream link or node, a transit router can reroute
traffic for fast service restoration. traffic for fast service restoration.
0x02 Label recording desired 0x02 Label recording desired
This flag indicates that label information should be This flag indicates that label information should be
included when doing a route record. included when doing a route record.
0x04 Ingress node may reroute 0x04 SE Style desired
This flag indicates that the tunnel ingress node may This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down. choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when A tunnel egress node SHOULD use the SE Style when
responding with a Resv message. responding with a Resv message.
Name Length Name Length
The length of the display string before padding, in bytes. The length of the display string before padding, in bytes.
Session Name Session Name
A null padded string of characters. A null padded string of characters.
4.8.3. Procedures applying to both C-Types 4.7.3. Procedures applying to both C-Types
The support of setup and holding priorities is OPTIONAL. A node can The support of setup and holding priorities is OPTIONAL. A node can
recognize this information but be unable to perform the requested recognize this information but be unable to perform the requested
operation. The node SHOULD pass the information downstream operation. The node SHOULD pass the information downstream
unchanged. unchanged.
As noted above, preemption is implemented by two priorities. The As noted above, preemption is implemented by two priorities. The
Setup Priority is the priority for taking resources. The Holding Setup Priority is the priority for taking resources. The Holding
Priority is the priority for holding a resource. Specifically, the Priority is the priority for holding a resource. Specifically, the
Holding Priority is the priority at which resources assigned to this Holding Priority is the priority at which resources assigned to this
session will be reserved. The Setup Priority SHOULD never be higher session will be reserved. The Setup Priority SHOULD never be higher
than the Holding Priority for a given session. than the Holding Priority for a given session.
The setup and holding priorities are directly analogous to the The setup and holding priorities are directly analogous to the
preemption and defending priorities as defined in [9]. While the preemption and defending priorities as defined in [9]. While the
interaction of these two objects is ultimately a matter of policy, interaction of these two objects is ultimately a matter of policy,
the following default interaction is recommended. the following default interaction is RECOMMENDED.
When both objects are present, the preemption priority policy element When both objects are present, the preemption priority policy element
is used. A mapping between the priority spaces is defined as is used. A mapping between the priority spaces is defined as
follows. A session attribute priority S is mapped to a preemption follows. A session attribute priority S is mapped to a preemption
priority P by the formula P = 2^(14-2S). The reverse mapping is priority P by the formula P = 2^(14-2S). The reverse mapping is
shown in the following table. shown in the following table.
Preemption Priority Session Attribute Priority Preemption Priority Session Attribute Priority
0 - 3 7 0 - 3 7
skipping to change at page 51, line 13 skipping to change at page 51, line 13
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 of the it is not automatically recorded. The for all applications, it is not automatically recorded. The flag
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 displayable 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.8.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
by RSVP in two ways. In order to be validated a link must pass the by RSVP in two ways. In order to be validated a link MUST pass the
three tests below. If the test fails a PathErr with the code "policy three tests below. If the test fails a PathErr with the code "policy
control failure" SHOULD be sent. control failure" SHOULD be sent.
When a new reservation is considered for admission over a strict node When a new reservation is considered for admission over a strict node
in an ERO, a node MAY validate the resource affinities with the in an ERO, a node MAY validate the resource affinities with the
resource classes of that link. When a node is choosing links in resource classes of that link. When a node is choosing links in
order to extend a loose node of an ERO, the node must validate the order to extend a loose node of an ERO, the node MUST validate the
resource classes of those links against the resource affinities. If resource classes of those links against the resource affinities. If
no acceptable links can be found to extend the ERO, the node SHOULD no acceptable links can be found to extend the ERO, the node SHOULD
send a PathErr message with an error code of "Routing Problem" and an send a PathErr message with an error code of "Routing Problem" and an
error value of "no route available toward destination". error value of "no route available toward destination".
In order to be validated a link must pass the following three tests. In order to be validated a link MUST pass the following three tests.
To precisely describe the tests use the definitions in the object To precisely describe the tests use the definitions in the object
description above. We also define description above. We also define
Link-attr A 32-bit vector representing attributes associated Link-attr A 32-bit vector representing attributes associated
with a link. with a link.
The three tests are The three tests are
1. Exclude-any 1. Exclude-any
skipping to change at page 52, line 29 skipping to change at page 52, line 29
(include-any == 0) | ((link-attr & include-any) != 0) (include-any == 0) | ((link-attr & include-any) != 0)
3. Include-all 3. Include-all
This test accepts a link only if the link carries all of the This test accepts a link only if the link carries all of the
attributes in the set. attributes in the set.
(include-all == 0) | (((link-attr & include-all) ^ include- (include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0) all) == 0)
For a link to be acceptable, all three tests must pass. If the test For a link to be acceptable, all three tests MUST pass. If the test
fails a error message fails a error message
If a Path message contains multiple SESSION_ATTRIBUTE objects, only If a Path message contains multiple SESSION_ATTRIBUTE objects, only
the first SESSION_ATTRIBUTE object is meaningful. Subsequent the first SESSION_ATTRIBUTE object is meaningful. Subsequent
SESSION_ATTRIBUTE objects can be ignored and need not be forwarded. SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.
All RSVP routers, whether they support the SESSION_ATTRIBUTE object All RSVP routers, whether they support the SESSION_ATTRIBUTE object
or not, SHALL forward the object unmodified. The presence of non- or not, SHALL forward the object unmodified. The presence of non-
RSVP routers anywhere between senders and receivers has no impact on RSVP routers anywhere between senders and receivers has no impact on
this object. this object.
4.9. Tspec and Flowspec Object for Class-of-Service Service 4.8. Tspec and Flowspec Object for Class-of-Service Service
An LSP may not need bandwidth reservations or QoS guarantees. Such An LSP may not need bandwidth reservations or QoS guarantees. Such
LSPs can be used to deliver best-effort traffic, even if RSVP is used LSPs can be used to deliver best-effort traffic, even if RSVP is used
for setting up LSPs. When resources do not have to be allocated to for setting up LSPs. When resources do not have to be allocated to
the LSP, the Class-of-Service service SHOULD be used. the LSP, the Class-of-Service service SHOULD be used.
The Class-of-Service FLOWSPEC allows indication of a Class of Service The Class-of-Service FLOWSPEC allows indication of a Class of Service
(CoS) value that should be used when handling data packets associated (CoS) value that should be used when handling data packets associated
with the request. with the request.
skipping to change at page 56, line 34 skipping to change at page 56, line 34
zero (0). zero (0).
Dst_Instance: 32 bits Dst_Instance: 32 bits
The most recently received Src_Instance value received from the The most recently received Src_Instance value received from the
neighbor. This field MUST be set to zero (0) when no value has neighbor. This field MUST be set to zero (0) when no value has
ever been seen from the neighbor. ever been seen from the neighbor.
5.3. Hello Message Usage 5.3. Hello Message Usage
The Hello Message is completely optional. All messages may be The Hello Message is completely OPTIONAL. All messages may be
ignored by nodes which do not wish to participate in Hello message ignored by nodes which do not wish to participate in Hello message
processing. The balance of this section is written assuming that the processing. The balance of this section is written assuming that the
receiver as well as the sender is participating. In particular, the receiver as well as the sender is participating. In particular, the
use of MUST and SHOULD with respect to the receiver applies only to a use of MUST and SHOULD with respect to the receiver applies only to a
node that supports Hello message processing. node that supports Hello message processing.
A node periodically generates a Hello message containing a HELLO A node periodically generates a Hello message containing a HELLO
REQUEST object for each neighbor who's status is being tracked. The REQUEST object for each neighbor who's status is being tracked. The
periodicity is governed by the hello_interval. This value MAY be periodicity is governed by the hello_interval. This value MAY be
configured on a per neighbor basis. The default value is 5 ms. configured on a per neighbor basis. The default value is 5 ms.
skipping to change at page 59, line 12 skipping to change at page 59, line 12
"Unknown Object Class" error. In either case the sender will fail to "Unknown Object Class" error. In either case the sender will fail to
see an acknowledgment for the issued Hello. see an acknowledgment for the issued Hello.
6. Security Considerations 6. Security Considerations
In principle these extensions to RSVP pose no security exposures over In principle these extensions to RSVP pose no security exposures over
and above RFC 2205[1]. However, there is a slight change in the and above RFC 2205[1]. However, there is a slight change in the
trust model. Traffic sent on a normal RSVP session can be filtered trust model. Traffic sent on a normal RSVP session can be filtered
according to source and destination addresses as well as port according to source and destination addresses as well as port
numbers. In this specification, filtering occurs only on the basis numbers. In this specification, filtering occurs only on the basis
of an incoming label. For this reason an administration may which to of an incoming label. For this reason an administration may wish to
limit the domain over which LSP tunnels can be established. This can limit the domain over which LSP tunnels can be established. This can
be accomplished by setting filters on various ports to deny action on be accomplished by setting filters on various ports to deny action on
a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7) a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7)
or LSP_TUNNEL_IPv6 (8). or LSP_TUNNEL_IPv6 (8).
7. IANA Considerations 7. IANA Considerations
The responsible Internet authority (presently called the IANA) The responsible Internet authority (presently called the IANA)
assigns values to RSVP protocol parameters. With the current assigns values to RSVP protocol parameters. With the current
document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are
 End of changes. 

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