draft-ietf-ccamp-gmpls-overlay-04.txt   draft-ietf-ccamp-gmpls-overlay-05.txt 
Network Working Group G. Swallow Network Working Group G. Swallow
Internet Draft Cisco Systems, Inc Internet Draft Cisco Systems, Inc
Category: Standards Track Category: Standards Track
Expiration Date: October 2004 Expiration Date: April 2005 J. Drake
J. Drake
Calient Networks, Inc Calient Networks, Inc
H. Ishimatsu H. Ishimatsu
Japan Telecom Japan Telecom
Y. Rekhter Y. Rekhter
Juniper Networks, Inc Juniper Networks, Inc
April 2004 October 2004
GMPLS UNI: RSVP Support for the Overlay Model Generalize Multiprotocol Label Switching(GMPLS)
User-Network Interface (UNI):
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support
for the Overlay Model
draft-ietf-ccamp-gmpls-overlay-04.txt draft-ietf-ccamp-gmpls-overlay-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. Internet-Drafts are working patent or other IPR claims of which I am aware have been disclosed,
documents of the Internet Engineering Task Force (IETF), its areas, and any of which I become aware will be disclosed, in accordance with
and its working groups. Note that other groups may also distribute RFC 3668.
working documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Generalized Multiprotocol Label Switching (GMPLS) defines both Generalized Multiprotocol Label Switching (GMPLS) defines both
routing and signaling protocols for the creation of Label Switched routing and signaling protocols for the creation of Label Switched
Paths (LSPs) in various transport technologies. These protocols can Paths (LSPs) in various switching technologies. These protocols can
be used to support a number of deployment scenarios. This memo be used to support a number of deployment scenarios. This memo
addresses the application of GMPLS to the overlay model. addresses the application of GMPLS to the overlay model.
Contents Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
1.1 GMPLS User-Network Interface (GMPLS UNI) ............... 4 1.1 GMPLS User-Network Interface (GMPLS UNI) ............... 4
2 Addressing ............................................. 5 2 Addressing ............................................. 5
3 ERO Processing ......................................... 6 3 ERO Processing ......................................... 6
3.1 Path Message without ERO ............................... 6 3.1 Path Message without ERO ............................... 6
3.2 Path Message with ERO .................................. 6 3.2 Path Message with ERO .................................. 6
3.3 Explicit Label Control ................................. 6 3.3 Explicit Label Control ................................. 7
4 RRO Processing ......................................... 7 4 RRO Processing ......................................... 7
5 Notification ........................................... 7 5 Notification ........................................... 7
6 Connection Deletion .................................... 7 6 Connection Deletion .................................... 8
6.1 Alarm-Free Connection Deletion ......................... 7 6.1 Alarm-Free Connection Deletion ......................... 8
6.2 Connection Deletion with PathErr ....................... 8 6.2 Connection Deletion with PathErr ....................... 8
7 VPN Connections ........................................ 8 7 VPN Connections ........................................ 9
8 Security Considerations ................................ 9 8 Security Considerations ................................ 9
9 Acknowledgments ........................................ 9 9 Acknowledgments ........................................ 9
10 References ............................................. 9 10 References ............................................. 10
10.1 Normative References ................................... 9 10.1 Normative References ................................... 10
10.2 Informative References ................................. 10 10.2 Informational References ............................... 10
11 Authors' Addresses ..................................... 10 11 Authors' Addresses ..................................... 11
12 Intellectual Property Notice ........................... 11 12 Intellectual Property Notice ........................... 11
12.1 IPR Disclosure Acknowledgement ......................... 11
13 Full Copyright Statement ............................... 12 13 Full Copyright Statement ............................... 12
1. Introduction 1. Introduction
Generalized Multiprotocol Label Switching (GMPLS) defines both Generalized Multiprotocol Label Switching (GMPLS) defines both
routing and signaling protocols for the creation of Label Switched routing and signaling protocols for the creation of Label Switched
Paths (LSPs) in various transport technologies. These protocols can Paths (LSPs) in various transport technologies. These protocols can
be used to support a number of deployment scenarios. In a peer be used to support a number of deployment scenarios. In a peer
model, edge-nodes support both a routing and a signaling protocol. model, edge-nodes support both a routing and a signaling protocol.
The protocol interactions between an edge-node and a core node are The protocol interactions between an edge-node and a core node are
the same as between two core-nodes. In the overlay model, the core- the same as between two core-nodes. In the overlay model, the
nodes act more as a closed system. The edge nodes do not participate core-nodes act more as a closed system. The edge nodes do not
in the routing protocol instance that runs among the core nodes; in participate in the routing protocol instance that runs among the core
particular, the edge nodes are unaware of the topology of the core nodes; in particular, the edge nodes are unaware of the topology of
nodes. There may, however, be a routing protocol interaction between the core nodes. There may, however, be a routing protocol
a core node and an edge node for the exchange of reachability interaction between a core node and an edge node for the exchange of
information to other edge nodes. reachability information to other edge nodes.
Overlay Overlay Overlay Overlay
Network +----------------------------------+ Network Network +----------------------------------+ Network
+---------+ | | +---------+ +---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ | | +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| -+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +- | | -+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +- |
| | | | +--+--| | | | | | | | | | | | | | | +--+--| | | | | | | | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ | | +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ |
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 3, line 52 skipping to change at page 3, line 52
Network Network Network Network
Legend: EN - Edge Node Legend: EN - Edge Node
CN - Core Node CN - Core Node
Figure 1: Overlay Reference Model Figure 1: Overlay Reference Model
Figure 1 shows a reference network. The core network is represented Figure 1 shows a reference network. The core network is represented
by the large box in the center. It contains five core-nodes marked by the large box in the center. It contains five core-nodes marked
'CN'. The four boxes around the edge marked "Overlay Network" 'CN'. The four boxes around the edge marked "Overlay Network"
represent four islands of a single network overlaid network. Only represent four islands of a single overlay network. Only
the nodes of this network with TE links into the core network are the nodes of this network with TE links into the core network are
shown. These nodes are called edge-nodes; the terminology is in shown. These nodes are called edge-nodes; the terminology is in
respect to the core network, not the overlay network. Note that each respect to the core network, not the overlay network. Note that each
box marked "Overlay Network" could contain many other nodes. Such box marked "Overlay Network" could contain many other nodes. Such
nodes are not shown; they do not participate in the signaling nodes are not shown; they do not participate directly in the
described in this document. Only the edge-nodes can signal to set up signaling described in this document. Only the edge-nodes can signal
links across the core to other edge-nodes. Once a link is to set up links across the core to other edge-nodes.
established, presumably the edge-node will inform the other nodes of
the overlay network of its existence. How this is accomplished is How a link between edge-nodes is requested and triggered is out of
beyond the scope of this document. However, one possible means is the scope of this document, as is precisely how that link is used by
using a forwarding adjacency as described in [MPLS-HIER]. the Overlay Network. One posibliity is that the edge-nodes will
inform the other nodes of the overlay network of the existence of the
link possibly using a forwarding adjacency as described in
[MPLS-HIER]. Note that this contrasts with a forwarding adjacency
that is provided by the core network as a link between core nodes.
In the overlay model there may be restrictions on what may be In the overlay model there may be restrictions on what may be
signaled between an edge-node and a core-node. This memo addresses signaled between an edge-node and a core-node. This memo addresses
the application of GMPLS to the overlay model. Specifically it the application of GMPLS to the overlay model. Specifically it
addresses RSVP procedures between an edge-node and a core-node in the addresses RSVP-TE procedures between an edge-node and a core-node in
overlay model. All RSVP procedures are assumed to be identical to the overlay model. All signaling procedures are identical to the
[RFC3473] except as noted in this document. GMPLS extensions specified in [RFC3473] except as noted in this
document.
This document primarily addresses interactions between an edge-node This document primarily addresses interactions between an edge-node
and it's adjacent (at the data plane) core-node. Except where noted, and it's adjacent (at the data plane) core-node - out-of-band and
the term core-node refers to the node which is immediately adjacent non-adjacent signaling capablities may mean that signaling messages
to an edge-node across a particular data plane interface. The term are delivered on a longer path. Except where noted, the term
core-node refers to the node which is immediately adjacent to an
edge-node across a particular data plane interface. The term
core-nodes, however, refers to all nodes in the core. core-nodes, however, refers to all nodes in the core.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Readers are assumed to be familiar with the terminology introduced in
[RFC3031], [GMPLS-ARCH] and [RFC3471].
1.1. GMPLS User-Network Interface (GMPLS UNI) 1.1. GMPLS User-Network Interface (GMPLS UNI)
One can apply the GMPLS Overlay model at the User-Network Interface One can apply the GMPLS Overlay model at the User-Network Interface
(UNI) reference point defined in the Automatically Switched Optical (UNI) reference point defined in the Automatically Switched Optical
Network (ASON) [G.8080]. Consider the case where the 'Core Network' Network (ASON) [G.8080]. Consider the case where the 'Core Network'
in Figure 1 is a Service Provider network, and the Edge Nodes are in Figure 1 is a Service Provider network, and the Edge Nodes are
'user' devices. The interface between EN and CN is the UNI reference 'user' devices. The interface between an EN and a CN is the UNI
point, and to support the ASON model, one must define signaling reference point, and to support the ASON model, one must define
across the UNI. signaling across the UNI.
The extensions described in this memo provide mechanisms for UNI The extensions described in this memo provide mechanisms for UNI
signaling that are compatible with GMPLS signaling [RFC3471, signaling that are compatible with GMPLS signaling [RFC3471,
RFC3473]. Moreover, these mechanisms for UNI signaling are in line RFC3473]. Moreover, these mechanisms for UNI signaling are in line
with the RSVP model, namely, there is a single end-to-end RSVP with the RSVP model, namely, there is a single end-to-end RSVP
session for the user connection. The first and last hops constitute session for the user connection. The first and last hops constitute
the UNI, and the RSVP session carries the user parameters end-to-end. the UNI, and the RSVP session carries the user parameters end-to-end.
This obviates the need to map (or carry) user parameters to (in) the This obviates the need to map (or carry) user parameters to (in) the
format expected by the network-to-network interface (NNI) used within format expected by the network-to-network interface (NNI) used within
the Service Provider network. This in turn means that the UNI and the Service Provider network. This in turn means that the UNI and
NNI can be independent of one another, which is a requirement of the NNI can be independent of one another, which is a requirement of the
ASON architecture. However, in the case that the UNI and NNI are ASON architecture. However, in the case that the UNI and NNI are
both GMPLS RSVP-based, the methodology specified in this memo allows both GMPLS RSVP-based, the methodology specified in this memo allows
for a single RSVP session to instantiate both UNI and NNI signaling, for a single RSVP session to instantiate both UNI and NNI signaling,
if so desired, and if allowed by Service Provider policy. if so desired, and if allowed by Service Provider policy.
2. Addressing 2. Addressing
Addresses for edge-nodes in the overlay model are drawn from the same Addresses for edge-nodes in the overlay model are drawn from the same
address space as the edge-nodes use to address their adjacent core- address space as the edge-nodes use to address their adjacent
nodes. This may be the same address space as used by the core-nodes core-nodes. This may be the same address space as used by the
to communicate among themselves or it may be a VPN space supported by core-nodes to communicate among themselves or it may be a VPN space
the core-nodes as an overlay. supported by the core-nodes as an overlay.
To be more specific, an edge-node and its attached core-node must To be more specific, an edge-node and its attached core-node must
share the same address space which is used by GMPLS. A set of share the same address space that is used by GMPLS to signal between
<edge-node, core-node> tuples share the same address space if the the edge-nodes across the core network. A set of <edge-node,
edge-nodes in the set could establish LSPs (through the core-nodes) core-node> tuples share the same address space if the edge-nodes in
among themselves (note that edge-nodes in the set may be a subset of the set could establish LSPs (through the core-nodes) among
all the edge-nodes). The address space used by the core-nodes to themselves without address mapping or translation (note that
communicate among themselves may, but need not be shared with the edge-nodes in the set may be a subset of all the edge-nodes). The
address space used by any of the <edge-node, core-node> tuples. address space used by the core-nodes to communicate among themselves
may, but need not be shared with the address space used by any of the
<edge-node, core-node> tuples.
When multiple overlay networks are supported by a single core network
one or more address spaces may be used according to privacy
requirements. This may be achieved without varying the core-node
addresses since it is the <edge-node, core-node> tuple that
constitues address space membership.
An edge-node is identified by either a single IP address representing An edge-node is identified by either a single IP address representing
its Node-ID, or by one or more numbered TE links that connect the its Node-ID, or by one or more numbered TE links that connect the
edge-node to the core-nodes. Core-nodes are assumed to be ignorant edge-node to the core-nodes. Core-nodes are assumed to be ignorant
of any other addresses associated with an edge-node (i.e. addresses of any other addresses associated with an edge-node (i.e. addresses
which are not used in signaling connections through the GMPLS core). which are not used in signaling connections through the GMPLS core).
An edge-node need only know its own address, an address of the An edge-node need only know its own address, an address of the
adjacent core-node, and know (or be able to resolve) the address of adjacent core-node, and know (or be able to resolve) the address of
any other edge-node to which it wishes to connect. any other edge-node to which it wishes to connect, as well as (of
course) the addresses used in the overlay network island of which
it is a part.
A core-node need only know (and track) the addresses on interfaces A core-node need only know (and track) the addresses on interfaces
between that core-node and its attached edge-nodes, as well as the between that core-node and its attached edge-nodes, as well as the
Node IDs of those edge-nodes. In addition, a core-node needs to know Node IDs of those edge-nodes. In addition, a core-node needs to know
the interface addresses and Node IDs of other edge-nodes to which an the interface addresses and Node IDs of other edge-nodes to which an
attached edge-node is permitted to connect. attached edge-node is permitted to connect.
When forming a SENDER_TEMPLATE the ingress edge-node includes either When forming a SENDER_TEMPLATE the ingress edge-node includes either
its Node-ID or the address of one of its numbered TE links. In the its Node-ID or the address of one of its numbered TE links. In the
latter case the connection will only be made over this interface. latter case the connection will only be made over this interface.
skipping to change at page 6, line 12 skipping to change at page 6, line 29
bundled or unbundled. See [GMPLS-ARCH], [RFC3471], [BUNDLE], and bundled or unbundled. See [GMPLS-ARCH], [RFC3471], [BUNDLE], and
[RFC3477]. [RFC3477].
3. ERO Processing 3. ERO Processing
An edge-node MAY include an ERO. A core-node MAY reject a Path An edge-node MAY include an ERO. A core-node MAY reject a Path
message that contains an ERO. Such behavior is controlled by message that contains an ERO. Such behavior is controlled by
(hopefully consistent) configuration. If a core-node rejects a Path (hopefully consistent) configuration. If a core-node rejects a Path
message due to the presence of an ERO it SHOULD return an PathErr message due to the presence of an ERO it SHOULD return an PathErr
message with an error code of "Unknown object class" toward the message with an error code of "Unknown object class" toward the
sender. This causes the path setup to fail. sender as described in [RFC3209]. This causes the path setup to fail.
Further a core-node MAY accept EROs which only include the ingress Further a core-node MAY accept EROs which only include the ingress
edge-node, the ingress core-node, the egress core-node and the egress edge-node, the ingress core-node, the egress core-node and the egress
edge-node. This is to support explicit label control on the edge- edge-node. This is to support explicit label control on the
node interface, see below. If a core-node rejects a Path message due edge-node interface, see below. If a core-node rejects a Path
to the presence of an ERO not of the permitted format it SHOULD message due to the presence of an ERO not of the permitted format it
return an PathErr message with an error code of Bad Explicit Route SHOULD return an PathErr message with an error code of Bad Explicit
Object as defined in [RFC3209]. Route Object as defined in [RFC3209].
3.1. Path Message without ERO 3.1. Path Message without ERO
When a core-node receives a Path message from an edge-node that When a core-node receives a Path message from an edge-node that
contains no ERO, it MUST calculate a route to the destination and contains no ERO, it MUST calculate a route to the destination and
include that route in a ERO, before forwarding the PATH message. One include that route in a ERO, before forwarding the PATH message. One
exception would be if the egress edge-node were also adjacent to this exception would be if the egress edge-node were also adjacent to this
core-node. If no route can be found, the core-node SHOULD return a core-node. If no route can be found, the core-node SHOULD return a
PathErr message with an error code and value of 24,5 - "No route PathErr message with an error code and value of 24,5 - "No route
available toward destination". available toward destination".
3.2. Path Message with ERO 3.2. Path Message with ERO
When a core-node receives a Path message from an edge-node that When a core-node receives a Path message from an edge-node that
contains an ERO, it SHOULD verify the route against its topology contains an ERO, it SHOULD verify the route against its topology
database before forwarding the PATH message. If the route is not database before forwarding the PATH message. If the route is not
viable, then a PathErr message with an error code and value of 24,5 - viable (according to topology, currently available resources, or
"No route available toward destination" should be returned. local policy), then a PathErr message with an error code and value of
24,5 - "No route available toward destination" should be returned.
3.3. Explicit Label Control 3.3. Explicit Label Control
In order to support explicit label control and full identification of In order to support explicit label control and full identification of
the egress link an ingress edge-node may include an ERO that consists the egress link an ingress edge-node may include this information in
of only the last hop. This is signaled by setting the first the ERO that it passes to its neighboring core-node. In the case that
subobject of the ERO to the node-ID of the egress core-node with the no other ERO is supplied, this explicit control information is
L-bit set. Following this subobject are all other subobjects provided as the only hop of the ERO and is encoded by setting the
first subobject of the ERO to the node-ID of the egress core-node
with the L-bit set; following this subobject are all other subobjects
necessary to identify the link and labels as they would normally necessary to identify the link and labels as they would normally
appear. appear.
The same rules apply to the presence of the explicit control
subobjects as the last hop in the ERO if a fuller ERO is supplied by
the ingress edge-node to its neighbor core-node, but in this case the
L-bit MAY be clear.
This process is described in [RFC3473] and [EXPLICIT]. This process is described in [RFC3473] and [EXPLICIT].
4. RRO Processing 4. RRO Processing
An edge-node MAY include an RRO. A core-node MAY remove the RRO from An edge-node MAY include an RRO. A core-node MAY remove the RRO from
the Path message before forwarding it. Further the core-node may the Path message before forwarding it. Further the core-node may
remove the RRO from a Resv message before forwarding it to the edge- remove the RRO from a Resv message before forwarding it to the
node. Such behavior is controlled by (hopefully consistent) edge-node. Such behavior is controlled by (hopefully consistent)
configuration. configuration.
Further a core-node MAY edit the RRO in a Resv message such that it Further a core-node MAY edit the RRO in a Resv message such that it
includes only the subobjects from the egress core-node through the includes only the subobjects from the egress core-node through the
egress edge-node. This is to allow the ingress node to be aware of egress edge-node. This is to allow the ingress node to be aware of
the selected link and labels on at the far end of the connection. the selected link and labels on at the far end of the connection.
5. Notification 5. Notification
An edge-node MAY include a NOTIFY_REQUEST object in both the Path and An edge-node MAY include a NOTIFY_REQUEST object in both the Path and
Resv messages it generates. Core-nodes may send Notification Resv messages it generates. Core-nodes may send Notify
messages to edge-nodes which have included the NOTIFY_REQUEST object. messages to edge-nodes which have included the NOTIFY_REQUEST object.
A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv
message received from an edge-node before forwarding it. message received from an edge-node before forwarding it.
If no NOTIFY_REQUEST object is present in the Path or Resv received If no NOTIFY_REQUEST object is present in the Path or Resv received
from an edge-node, the core-node adjacent to the edge-node may from an edge-node, the core-node adjacent to the edge-node may
include a NOTIFY_REQUEST object and set its value to its own address. include a NOTIFY_REQUEST object and set its value to its own address.
In either of the above cases, the a core-node SHOULD NOT send Notify In either of the above cases, the core-node SHOULD NOT send Notify
messages to the edge-node. messages to the edge-node.
When a core-node receives a NOTIFY_REQUEST object from an edge-node, When a core-node receives a NOTIFY_REQUEST object from an edge-node,
it MAY update the Notify Node Address with its own address before it MAY update the Notify Node Address with its own address before
forwarding it. In this case, when NOTIFY messages are received, they forwarding it. In this case, when Notify messages are received, they
MAY be selectively (based on local policy) forwarded to the edge- MAY be selectively (based on local policy) forwarded to the
node. edge-node.
6. Connection Deletion 6. Connection Deletion
6.1. Alarm-Free Connection Deletion 6.1. Alarm-Free Connection Deletion
RSVP currently deletes connections using either a single pass RSVP-TE currently deletes connections using either a single pass
PathTear message, or a ResvTear and PathTear message combination. PathTear message, or a ResvTear and PathTear message combination.
Upon receipt of the PathTear message, a node deletes the connection Upon receipt of the PathTear message, a node deletes the connection
state and forwards the message. In optical networks, however, it is state and forwards the message. In optical networks, however, it is
possible that the deletion of a connection (e.g., removal of the possible that the deletion of a connection (e.g., removal of the
cross-connect) in a node may cause the connection to be perceived as cross-connect) in a node may cause the connection to be perceived as
failed in downstream nodes (e.g., loss of frame, loss of light, failed in downstream nodes (e.g., loss of frame, loss of light,
etc.). This may in turn lead to management alarms and perhaps the etc.). This may in turn lead to management alarms and perhaps the
triggering of restoration/protection for the connection. triggering of restoration/protection for the connection.
To address this issue, the graceful connection deletion procedure To address this issue, the graceful connection deletion procedure
skipping to change at page 8, line 23 skipping to change at page 8, line 43
be deleted MAY pause the PathTear and first send a Path message with be deleted MAY pause the PathTear and first send a Path message with
an ADMIN_STATUS object to inform all downstream LSRs that the an ADMIN_STATUS object to inform all downstream LSRs that the
connection is about to be deleted. When the Resv is received echoing connection is about to be deleted. When the Resv is received echoing
the ADMIN_STATUS or using a timer as described in [RFC3473], the the ADMIN_STATUS or using a timer as described in [RFC3473], the
ingress core-node MUST forward the PathTear. ingress core-node MUST forward the PathTear.
6.2. Connection Deletion with PathErr 6.2. Connection Deletion with PathErr
[RFC3473] introduces the Path_State_Removed flag to a PathErr message [RFC3473] introduces the Path_State_Removed flag to a PathErr message
to indicate that the sender has removed all state associated with the to indicate that the sender has removed all state associated with the
LSP and does not need to see a PathTear. A code-node next to an edge- LSP and does not need to see a PathTear. A core-node next to an
node MAY map between teardown using ResvTear/PathTear and PathErr edge-node MAY map between teardown using ResvTear/PathTear and
with Path_state_Removed. PathErr with Path_state_Removed.
- A core-node next to an edge-node receiving a ResvTear from its A core-node next to an edge-node receiving a ResvTear from its
downstream neighbor MAY respond with a PathTear and send a downstream neighbor MAY respond with a PathTear and send a PathErr
PathErr with Path_State_Removed further upstream. with Path_State_Removed further upstream.
- A core-node next to an edge-node receiving a PathErr with Note, however, that a core-node next to an edge-node receiving a
Path_State_Removed from its downstream neighbor MAY retain Path PathErr with Path_State_Removed from its downstream neighbor MUST NOT
state and send a ResvTear further upstream. retain Path state and send a ResvTear further upstream since that
would imply that Path state further downstream had also been
retained.
7. VPN Connections 7. VPN Connections
As stated in the addressing section above, the extensions in this As stated in the addressing section above, the extensions in this
document are designed to be compatible with the support of VPNs. document are designed to be compatible with the support of VPNs.
Since the core network may be some technology other than GMPLS, no Since the core network may be some technology other than GMPLS, no
mandatory means of mapping core connections to access connections is mandatory means of mapping core connections to access connections is
specified. However, when GMPLS is used for the core network, we specified. However, when GMPLS is used for the core network, it is
RECOMMEND the following procedure which is based on [LSP-HIER]. RECOMMENDED that the following procedure based on [LSP-HIER] is
followed.
The VPN connection is modeled as being three hops. One for each The VPN connection is modeled as being three hops. One for each
access link and one hop across the core network. access link and one hop across the core network.
The VPN connection is established using a two step procedure. When a The VPN connection is established using a two step procedure. When a
Path message is received at a core node on an interface which is part Path message is received at a core node on an interface which is part
of a VPN, the Path message is held until a core connection is of a VPN, the Path message is held until a core connection is
established. established.
The connection across the core is setup as a separate signaling The connection across the core is setup as a separate signaling
skipping to change at page 9, line 32 skipping to change at page 9, line 50
This draft imposes no new security risks over [RFC3473]. In fact it This draft imposes no new security risks over [RFC3473]. In fact it
represents a lower trust model between the core and edge-nodes as the represents a lower trust model between the core and edge-nodes as the
core is permitted to hide its topology from the edge-nodes. The core core is permitted to hide its topology from the edge-nodes. The core
is also permitted to restrict the actions of edge-nodes by filtering is also permitted to restrict the actions of edge-nodes by filtering
out specific RSVP objects. out specific RSVP objects.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Kireeti Kompella, Jonathan Lang, The authors would like to thank Kireeti Kompella, Jonathan Lang,
Dimitri Papadimitriou, Dimitrios Pendarakis, Bala Rajagopalan, and Dimitri Papadimitriou, Dimitrios Pendarakis, Bala Rajagopalan, and
Adrian Farrel for their comments and input. Adrian Farrel for their comments and input. Thanks for thorough final
reviews from Loa Andersson and Dimitri Papadimitriou.
Adrian Farrel edited the last two revisions of this document to
incorporate comments from Working Group last call and from AD review.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RFC3471] Berger, L., "Generalized MPLS Signaling Functional [RFC3471] Berger, L., "Generalized MPLS Signaling Functional
Description", RFC 3471, January 2003. Description", RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized MPLS Signaling RSVP-TE [RFC3473] Berger, L., "Generalized MPLS Signaling RSVP-TE
Extensions", RFC 3473, January 2003. Extensions", RFC 3473, January 2003.
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
10.2. Informative References 10.2. Informational References
[GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching (GMPLS) Architecture", draft-ietf-ccamp- Label Switching Architecture", RFC 3031, January 2001.
gmpls-architecture-04.txt, February 2003, work in
[RFC3477] Kompella, K., and Rekhter, Y., "Signaling Unnumbered
Links in RSVP-TE", RFC 3477, January 2003.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering",
draft-ietf-mpls-bundle-04.txt, July 2002, work in
progress. progress.
[EXPLICIT] Berger, L., "GMPLS Signaling Procedure For Egress
Control", draft-ccamp-gmpls-egress-control-02.txt,
May 2004, work in progress.
[GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture",
draft-ietf-ccamp-gmpls-architecture-07.txt, May 2003,
work in progress.
[MPLS-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with [MPLS-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt,
September 2001, work in progress. September 2001, work in progress.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering", draft-ietf-mpls-
bundle-04.txt, July 2002, work in progress.
[RFC3477] Kompella, K., and Rekhter, Y., "Signaling Unnumbered
Links in RSVP-TE", RFC 3477, January 2003.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON)," Automatically Switched Optical Network (ASON),"
November 2001 (and Revision, January 2003). November 2001 (and Revision, January 2003).
For information on the availability of this document,
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate please see http://www.itu.int.
Requirement Levels," RFC 2119.
[EXPLICIT] Berger, L., "GMPLS Signaling Procedure For Egress
Control", draft-ccamp-gmpls-egress-control-00.txt,
March 2004, work in progress.
11. Authors' Addresses 11. Authors' Addresses
John Drake John Drake
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972 3720 Phone: +1 408 972 3720
Email: jdrake@calient.net Email: jdrake@calient.net
skipping to change at page 11, line 35 skipping to change at page 12, line 11
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
12.1 IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights. rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
 End of changes. 

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