draft-ietf-ccamp-gmpls-overlay-00.txt   draft-ietf-ccamp-gmpls-overlay-01.txt 
Network Working Group George Swallow Network Working Group George Swallow
Internet Draft Cisco Systems, Inc Internet Draft Cisco Systems, Inc
Expiration Date: July 2003 Expiration Date: August 2003
John Drake John Drake
Calient Networks, Inc Calient Networks, Inc
Hirokazu Ishimatsu Hirokazu Ishimatsu
Japan Telecom Japan Telecom
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc Juniper Networks, Inc
January 2003 February 2003
GMPLS RSVP Support for the Overlay Model GMPLS RSVP Support for the Overlay Model
draft-ietf-ccamp-gmpls-overlay-00.txt draft-ietf-ccamp-gmpls-overlay-01.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."
To view the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow http://www.ietf.org/1id-abstracts.html
Directory, see http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Generalized MPLS defines both routing and signaling protocols for the Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport creation of Label Switched Paths (LSPs) in various transport
technologies. These protocols can be used to support a number of technologies. These protocols can be used to support a number of
deployment scenarios. This memo addresses the application of GMPLS deployment scenarios. This memo addresses the application of GMPLS
to the overlay model. to the overlay model.
Contents Contents
skipping to change at page 3, line 4 skipping to change at page 2, line 22
3.3 Explicit Label Control ................................. 6 3.3 Explicit Label Control ................................. 6
4 RRO Processing ......................................... 6 4 RRO Processing ......................................... 6
5 Notification ........................................... 7 5 Notification ........................................... 7
6 Connection Deletion .................................... 7 6 Connection Deletion .................................... 7
7 Security Considerations ................................ 7 7 Security Considerations ................................ 7
8 Acknowledgments ........................................ 8 8 Acknowledgments ........................................ 8
9 References ............................................. 8 9 References ............................................. 8
9.1 Normative References ................................... 8 9.1 Normative References ................................... 8
9.2 Informative References ................................. 8 9.2 Informative References ................................. 8
10 Authors' Addresses ..................................... 9 10 Authors' Addresses ..................................... 9
11 Full Copywrite Statement ............................... 9
1. Introduction 1. Introduction
Generalized MPLS defines both routing and signaling protocols for the Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport creation of Label Switched Paths (LSPs) in various transport
technologies. These protocols can be used to support a number of technologies. These protocols can be used to support a number of
deployment scenarios. In a peer model, edge-nodes support both a deployment scenarios. In a peer model, edge-nodes support both a
routing and a signaling protocol. The protocol interactions between routing and a signaling protocol. The protocol interactions between
an edge-node and a core node are the same as between two core-nodes. an edge-node and a core node are the same as between two core-nodes.
In the overlay model, the core-nodes act more as a closed system. In the overlay model, the core-nodes act more as a closed system.
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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"
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 signalling
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 using a forwarding beyond the scope of this document. However, one possible means is
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
overlay model. All RSVP procedures are assumed to be identical to overlay model. All RSVP procedures are assumed to be identical to
[GMPLS-RSVP] except as noted in this document. [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. 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].
skipping to change at page 5, line 31 skipping to change at page 5, line 31
latter case the connection will only be made over this interface. latter case the connection will only be made over this interface.
When forming a SESSION_OBJECT, the ingress edge-node includes either When forming a SESSION_OBJECT, the ingress edge-node includes either
the Node-ID of the egress edge-device or the address of one of the the Node-ID of the egress edge-device or the address of one of the
egress' numbered TE links. In the latter case the connection will egress' numbered TE links. In the latter case the connection will
only be made over this interface. The Extended_Tunnel_ID of the only be made over this interface. The Extended_Tunnel_ID of the
SESSION Object is set to either zero or to an address of the ingress SESSION Object is set to either zero or to an address of the ingress
edge-device. edge-device.
Links may be either numbered or unnumbered. Further, links may be Links may be either numbered or unnumbered. Further, links may be
bundled or unbundled. See [GMPLS-ARCH], [GMPLS-SIG], [BUNDLE], and bundled or unbundled. See [GMPLS-ARCH], [RFC3471], [BUNDLE], and
[RSVP-TE-UNUM]. [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. This causes the path setup to fail.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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 [GMPLS- deletion of the connection. The procedure is described in [RFC3473].
RSVP].
7. Security Considerations 7. Security Considerations
This draft imposes no new security risks over [GMPLS-RSVP]. In fact This draft imposes no new security risks over [RFC3473]. In fact it
it represents a lower trust model between the core and edge-nodes as represents a lower trust model between the core and edge-nodes as the
the core is permitted to hide its topology from the edge-nodes. The core is permitted to hide its topology from the edge-nodes. The core
core is also permitted to restrict the actions of edge-nodes by is also permitted to restrict the actions of edge-nodes by filtering
filtering out specific RSVP objects. out specific RSVP objects.
8. Acknowledgments 8. 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 9. References
9.1. Normative References 9.1. Normative References
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [RFC3471] Berger, L., "Generalized MPLS Signaling Functional
Signaling Functional Description", Internet Draft, Description", RFC 3471, January 2003.
draft-ietf-mpls-generalized-signaling-08.txt,
April 2002.
[GMPLS-RSVP] Ashwood-Smith, P. et. al, "Generalized MPLS - RSVP-TE [RFC3473] Berger, L., "Generalized MPLS Signaling RSVP-TE
Signaling Functional Description", Extensions", RFC 3473, January 2003.
draft-ietf-mpls-generalized-rsvp-te-07.txt,
April 2002.
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205, -- Version 1 Functional Specification", RFC 2205,
September 1997. September 1997.
[RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction [RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001 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 9.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-03.txt, Aug., 2002. 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.
[RSVP-UNNUM] Kompella, K., and Rekhter, Y., "Signalling Unnumbered [RFC3477] Kompella, K., and Rekhter, Y., "Signalling Unnumbered
Links in RSVP-TE", Internet Draft, Links in RSVP-TE", RFC 3477, January 2003.
draft-ietf-mpls-rsvp-unnum-07.txt, July, 2002.
[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 10. Authors' Addresses
<need info for other authors>
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
skipping to change at line 361 skipping to change at page 9, line 30
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 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: +1 978 497 8143 Phone: +1 978 497 8143
Email: swallow@cisco.com Email: swallow@cisco.com
11. Full Copywrite Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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