draft-ietf-ccamp-gmpls-overlay-02.txt   draft-ietf-ccamp-gmpls-overlay-03.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: April 2004 Expiration Date: August 2004
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
October 2003 February 2004
GMPLS UNI: RSVP Support for the Overlay Model GMPLS UNI: RSVP Support for the Overlay Model
draft-ietf-ccamp-gmpls-overlay-02.txt draft-ietf-ccamp-gmpls-overlay-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 (2003). 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 transport 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-to-Network Interface ........................ 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 .................................. 7
3.3 Explicit Label Control ................................. 7 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
7 VPN Connections ........................................ 8 6.1 Alarm-Free Connection Deletion ......................... 8
8 Security Considerations ................................ 9 6.2 Connection Deletion with PathErr ....................... 8
9 Acknowledgments ........................................ 9 7 VPN Connections ........................................ 9
10 References ............................................. 9 8 Security Considerations ................................ 10
10.1 Normative References ................................... 9 9 Acknowledgments ........................................ 10
10.2 Informative References ................................. 9 10 References ............................................. 10
11 Authors' Addresses ..................................... 10 10.1 Normative References ................................... 10
12 Full Copyright Statement ............................... 10 10.2 Informative References ................................. 10
11 Authors' Addresses ..................................... 11
12 Intellectual Property Notice ........................... 11
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 core-
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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 network overlaid 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 in the signaling
described in this document. Only he edge-nodes can signal to set up described in this document. Only the edge-nodes can signal to set up
links across the core to other edge-nodes. Once a link is links across the core to other edge-nodes. Once a link is
established, presumably the edge-node will inform the other nodes of established, presumably the edge-node will inform the other nodes of
the overlay network of its existence. How this is accomplished is the overlay network of its existence. How this is accomplished is
beyond the scope of this document. However, one possible means is beyond the scope of this document. However, one possible means is
using a forwarding adjacency as described in [MPLS-HIER]. using a forwarding adjacency as described in [MPLS-HIER].
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 procedures between an edge-node and a core-node in the
skipping to change at page 4, line 34 skipping to change at page 4, line 34
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. Except where noted,
the term core-node refers to the node which is immediately adjacent the term core-node refers to the node which is immediately adjacent
to an edge-node across a particular data plane interface. The term 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].
1.1. GMPLS User-to-Network Interface 1.1. GMPLS User-Network Interface (GMPLS UNI)
One can apply the GMPLS Overlay model at the User-to-Network One can apply the GMPLS Overlay model at the User-Network Interface
Interface (UNI) reference point defined in the Automatically Switched (UNI) reference point defined in the Automatically Switched Optical
Optical Network (ASON) [G.8080]. Consider the case where the 'Core Network (ASON) [G.8080]. Consider the case where the 'Core Network'
Network' in Figure 1 is a Service Provider network, and the Edge in Figure 1 is a Service Provider network, and the Edge Nodes are
Nodes are 'user' devices. The interface between EN and CN is the UNI 'user' devices. The interface between EN and CN is the UNI reference
reference point, and to support the ASON model, one must define point, and to support the ASON model, one must define signaling
signaling across the UNI. 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
skipping to change at page 7, line 31 skipping to change at page 7, line 39
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. A core-node MAY remove the Resv messages it generates. Core-nodes may send Notification
NOTIFY_REQUEST object from the Path or Resv message before forwarding messages to edge-nodes which have included the NOTIFY_REQUEST object.
it. Core-nodes may send Notification messages to edge-nodes which
have included the NOTIFY_REQUEST object.
Further if no NOTIFY_REQUEST object is present in the Path or Resv A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv
message (either because it was not included or because it was message received from an edge-node before forwarding it.
removed) then the core-node adjacent to the edge-node may include a
NOTIFY_REQUEST object to set its value to its own address. 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
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
messages to the 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
forwarding it. In this case, when NOTIFY messages are received, they
MAY be selectively (based on local policy) forwarded to the edge-
node.
6. Connection Deletion 6. Connection Deletion
6.1. Alarm-Free Connection Deletion
RSVP currently deletes connections using either a single pass RSVP 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
SHOULD be followed. Under this procedure, an ADMIN_STATUS object MUST SHOULD be followed. Under this procedure, an ADMIN_STATUS object MUST
be sent in Path or Resv message along the connection's path to inform be sent in Path or Resv message along the connection's path to inform
all nodes enroute of the intended deletion, prior to the actual all nodes enroute of the intended deletion, prior to the actual
deletion of the connection. The procedure is described in [RFC3473]. deletion of the connection. The procedure is described in [RFC3473].
An ingress core-node receiving a PathTear without having first seen
an ADMIN_STATUS object informing it that the connection is about to
be deleted MAY pause the PathTear and first send a Path message with
an ADMIN_STATUS object to inform all downstream LSRs that the
connection is about to be deleted. When the Resv is received echoing
the ADMIN_STATUS or using a timer as described in [RFC3473], the
ingress core-node MUST forward the PathTear.
6.2. Connection Deletion with PathErr
[RFC3473] introduces the Path_State_Removed flag to a PathErr message
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-
node MAY map between teardown using ResvTear/PathTear and PathErr
with Path_state_Removed.
- A core-node next to an edge-node receiving a ResvTear from its
downstream neighbor MAY respond with a PathTear and send a
PathErr with Path_State_Removed further upstream.
- A core-node next to an edge-node receiving a PathErr with
Path_State_Removed from its downstream neighbor MAY retain Path
state and send a ResvTear further upstream.
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, we
RECOMMEND the following procedure which is based on [LSP-HIER]. RECOMMEND the following procedure which is based on [LSP-HIER].
The VPN connection is modeled as being three hops. One for each The VPN connection is modeled as being three hops. One for each
skipping to change at page 9, line 16 skipping to change at page 10, line 16
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 and Bala Rajagopalan for Dimitri Papadimitriou, Dimitrios Pendarakis, Bala Rajagopalan, and
their comments and input. Adrian Farrel for their comments and input.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
skipping to change at page 10, line 38 skipping to change at page 11, line 38
Juniper Networks, Inc. Juniper Networks, Inc.
Email: yakov@juniper.net Email: yakov@juniper.net
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave, 1414 Massachusetts Ave,
Boxborough, MA 01719 Boxborough, MA 01719
Phone: +1 978 936 1398 Phone: +1 978 936 1398
Email: swallow@cisco.com Email: swallow@cisco.com
12. Full Copyright Statement 12. Intellectual Property Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11 [RFC2028].
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat. The IETF
invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
13. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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