draft-ietf-ccamp-gmpls-overlay-01.txt   draft-ietf-ccamp-gmpls-overlay-02.txt 
Network Working Group G. Swallow
Network Working Group George Swallow
Internet Draft Cisco Systems, Inc Internet Draft Cisco Systems, Inc
Expiration Date: August 2003 Category: Standards Track
John Drake Expiration Date: April 2004
J. Drake
Calient Networks, Inc Calient Networks, Inc
Hirokazu Ishimatsu H. Ishimatsu
Japan Telecom Japan Telecom
Yakov Rekhter Y. Rekhter
Juniper Networks, Inc Juniper Networks, Inc
February 2003 October 2003
GMPLS RSVP Support for the Overlay Model GMPLS UNI: RSVP Support for the Overlay Model
draft-ietf-ccamp-gmpls-overlay-01.txt draft-ietf-ccamp-gmpls-overlay-02.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 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 (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Generalized MPLS defines both routing and signaling protocols for the Generalized Multiprotocol Label Switching (GMPLS) defines both
creation of Label Switched Paths (LSPs) in various transport routing and signaling protocols for the creation of Label Switched
technologies. These protocols can be used to support a number of Paths (LSPs) in various transport technologies. These protocols can
deployment scenarios. This memo addresses the application of GMPLS be used to support a number of deployment scenarios. This memo
to the overlay model. addresses the application of GMPLS to the overlay model.
Contents Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
2 Addressing ............................................. 4 1.1 GMPLS User-to-Network Interface ........................ 4
3 ERO Processing ......................................... 5 2 Addressing ............................................. 5
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 ......................................... 6 4 RRO Processing ......................................... 7
5 Notification ........................................... 7 5 Notification ........................................... 7
6 Connection Deletion .................................... 7 6 Connection Deletion .................................... 7
7 Security Considerations ................................ 7 7 VPN Connections ........................................ 8
8 Acknowledgments ........................................ 8 8 Security Considerations ................................ 9
9 References ............................................. 8 9 Acknowledgments ........................................ 9
9.1 Normative References ................................... 8 10 References ............................................. 9
9.2 Informative References ................................. 8 10.1 Normative References ................................... 9
10 Authors' Addresses ..................................... 9 10.2 Informative References ................................. 9
11 Full Copywrite Statement ............................... 9 11 Authors' Addresses ..................................... 10
12 Full Copyright Statement ............................... 10
1. Introduction 1. Introduction
Generalized MPLS defines both routing and signaling protocols for the Generalized Multiprotocol Label Switching (GMPLS) defines both
creation of Label Switched Paths (LSPs) in various transport routing and signaling protocols for the creation of Label Switched
technologies. These protocols can be used to support a number of Paths (LSPs) in various transport technologies. These protocols can
deployment scenarios. In a peer model, edge-nodes support both a be used to support a number of deployment scenarios. In a peer
routing and a signaling protocol. The protocol interactions between model, edge-nodes support both a routing and a signaling protocol.
an edge-node and a core node are the same as between two core-nodes. The protocol interactions between an edge-node and a core node are
In the overlay model, the core-nodes act more as a closed system. the same as between two core-nodes. In the overlay model, the core-
The edge nodes do not participate in the routing protocol instance nodes act more as a closed system. The edge nodes do not participate
that runs among the core nodes; in particular, the edge nodes are in the routing protocol instance that runs among the core nodes; in
unaware of the topology of the core nodes. There may, however, be a particular, the edge nodes are unaware of the topology of the core
routing protocol interaction between a core node and an edge node for nodes. There may, however, be a routing protocol interaction between
the exchange of reachability information to other edge nodes. a core node and an edge node for the exchange of reachability
information to other edge nodes.
Overlay Overlay Overlay Overlay
Network +----------------------------------+ Network Network +----------------------------------+ Network
+----------+ | | +----------+ +---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ | | +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| --+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +-- | | -+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +- |
| | | | +--+--| | | | | | | | | | | | | | | +--+--| | | | | | | | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ | | +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ |
| | | | | | | | | | | | | | | | | | | |
+----------+ | | | | | | +----------+ +---------+ | | | | | | +---------+
| | | | | | | | | | | |
+----------+ | | | | | | +----------+ +---------+ | | | | | | +---------+
| | | | +--+--+ | +--+--+ | | | | | | | +--+--+ | +--+--+ | | |
| +----+ | | | | | +-------+ | | | +----+ | | +----+ | | | | | +-------+ | | | +----+ |
| | +-+--+ | | CN +---------------+ CN | | | | | | | | +-+--+ | | CN +---------------+ CN | | | | | |
| --+ EN +-+-----+--+ | | +---+-----+-+ EN +-- | | -+ EN +-+-----+--+ | | +---+-----+-+ EN +- |
| | | | | +-----+ +-----+ | | | | | | | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ | | +----+ | | | | +----+ |
| | +----------------------------------+ | | | | +----------------------------------+ | |
+----------+ Core Network +----------+ +---------+ Core Network +---------+
Overlay Overlay Overlay Overlay
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 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 signalling 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 he 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
skipping to change at page 4, line 33 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
One can apply the GMPLS Overlay model at the User-to-Network
Interface (UNI) reference point defined in the Automatically Switched
Optical Network (ASON) [G.8080]. Consider the case where the 'Core
Network' 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 point, and to support the ASON model, one must define
signaling across the UNI.
The extensions described in this memo provide mechanisms for UNI
signaling that are compatible with GMPLS signaling [RFC3471,
RFC3473]. Moreover, these mechanisms for UNI signaling are in line
with the RSVP model, namely, there is a single end-to-end RSVP
session for the user connection. The first and last hops constitute
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
format expected by the network-to-network interface (NNI) used within
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
ASON architecture. However, in the case that the UNI and NNI are
both GMPLS RSVP-based, the methodology specified in this memo allows
for a single RSVP session to instantiate both UNI and NNI signaling,
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 core-
nodes. This may be the same address space as used by the core-nodes nodes. This may be the same address space as used by the core-nodes
to communicate among themselves or it may be a VPN space supported by to communicate among themselves or it may be a VPN space supported by
the core-nodes as an overlay. 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 which is used by GMPLS. A set of
skipping to change at page 7, line 36 skipping to change at page 8, line 13
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].
7. Security Considerations 7. VPN Connections
As stated in the addressing section above, the extensions in this
document are designed to be compatible with the support of VPNs.
Since the core network may be some technology other than GMPLS, no
mandatory means of mapping core connections to access connections is
specified. However, when GMPLS is used for the core network, we
RECOMMEND the following procedure which is based on [LSP-HIER].
The VPN connection is modeled as being three hops. One for each
access link and one hop across the core network.
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
of a VPN, the Path message is held until a core connection is
established.
The connection across the core is setup as a separate signaling
exchange between the core nodes, using the address space of the core
nodes. While this exchange is in progress, the original Path message
is held at the ingress core node. Once the exchange for the core
connection is complete, this connection is used in the VPN connection
as if it were a single link. This is signaled by including an IF_ID
RSVP_HOP object (defined in [RFC3473]) using the procedures defined
in [LSP-HIER].
The original Path message is then forwarded within the VPN addressing
realm to the core node attached to the destination edge node. Many
ways of accomplishing this are available, including IP and GRE
tunnels and BGP/MPLS VPNs. Specifying a particular means is beyond
the scope of this document.
8. Security Considerations
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.
8. 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 and Bala Rajagopalan for
their comments and input. their comments and input.
9. References 10. References
9.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.
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001
[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.
9.2. Informative References 10.2. Informative References
[GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol [GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture", Internet Draft, Label Switching (GMPLS) Architecture", Internet Draft,
draft-ietf-ccamp-gmpls-architecture-04.txt, Feb., 2003. draft-ietf-ccamp-gmpls-architecture-04.txt, Feb., 2003.
[MPLS-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with [MPLS-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
MPLS TE", Internet Draft, MPLS TE", Internet Draft,
draft-ietf-mpls-lsp-hierarchy-08.txt, Sep., 2001. draft-ietf-mpls-lsp-hierarchy-08.txt, Sep., 2001.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering", Internet Draft, Bundling in MPLS Traffic Engineering", Internet Draft,
draft-ietf-mpls-bundle-04.txt, July, 2002. draft-ietf-mpls-bundle-04.txt, July, 2002.
[RFC3477] Kompella, K., and Rekhter, Y., "Signalling Unnumbered [RFC3477] Kompella, K., and Rekhter, Y., "Signaling Unnumbered
Links in RSVP-TE", RFC 3477, January 2003. Links in RSVP-TE", RFC 3477, January 2003.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON),"
November 2001 (and Revision, January 2003).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
10. 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
Hirokazu Ishimatsu Hirokazu Ishimatsu
Japan Telecom Co., Ltd. Japan Telecom Co., Ltd.
2-9-1 Hatchobori, Chuo-ku, Tokyo, 104-0032, Japan 2-9-1 Hatchobori, Chuo-ku, Tokyo, 104-0032, Japan
Tel: +81 3 5540 8493 Tel: +81 3 5540 8493
Email: hirokazu.ishimatsu@japan-telecom.co.jp Email: hirokazu.ishimatsu@japan-telecom.co.jp
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
Email: yakov@juniper.net Email: yakov@juniper.net
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 1414 Massachusetts Ave,
Chelmsford, MA 01824 Boxborough, MA 01719
Phone: +1 978 497 8143 Phone: +1 978 936 1398
Email: swallow@cisco.com Email: swallow@cisco.com
11. Full Copywrite Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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
 End of changes. 

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