Internet DRAFT - draft-ccamp-gmpls-overlay
draft-ccamp-gmpls-overlay
Network Working Group George Swallow
Internet Draft Cisco Systems, Inc
Expiration Date: July 2003
John Drake
Calient Networks, Inc
Hirokazu Ishimatsu
Japan Telecom
Yakov Rekhter
Juniper Networks, Inc
January 2003
GMPLS RSVP Support for the Overlay Model
draft-ccamp-gmpls-overlay-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract
Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport
technologies. These protocols can be used to support a number of
deployment scenarios. This memo addresses the application of GMPLS
to the overlay model.
Swallow, et al. [Page 1]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
Contents
1 Introduction ........................................... 3
2 Addressing ............................................. 4
3 ERO Processing ......................................... 5
3.1 Path Message without ERO ............................... 6
3.2 Path Message with ERO .................................. 6
3.3 Explicit Label Control ................................. 6
4 RRO Processing ......................................... 6
5 Notification ........................................... 7
6 Connection Deletion .................................... 7
7 Security Considerations ................................ 7
8 Acknowledgments ........................................ 8
9 References ............................................. 8
9.1 Normative References ................................... 8
9.2 Informative References ................................. 8
10 Authors' Addresses ..................................... 9
Swallow, et al. [Page 2]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
1. Introduction
Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport
technologies. These protocols can be used to support a number of
deployment scenarios. In a peer model, edge-nodes support both a
routing and a signaling protocol. 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-nodes act more as a closed system.
The edge nodes do not participate in the routing protocol instance
that runs among the core nodes; in particular, the edge nodes are
unaware of the topology of the core nodes. There may, however, be a
routing protocol interaction between a core node and an edge node for
the exchange of reachability information to other edge nodes.
Overlay Overlay
Network +----------------------------------+ Network
+----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| --+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +-- |
| | | | +--+--| | | | | | | | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ |
| | | | | | | | | |
+----------+ | | | | | | +----------+
| | | | | |
+----------+ | | | | | | +----------+
| | | | +--+--+ | +--+--+ | | |
| +----+ | | | | | +-------+ | | | +----+ |
| | +-+--+ | | CN +---------------+ CN | | | | | |
| --+ EN +-+-----+--+ | | +---+-----+-+ EN +-- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +----------------------------------+ | |
+----------+ Core Network +----------+
Overlay Overlay
Network Network
Legend: EN - Edge Node
CN - Core Node
Figure 1: Overlay Reference Model
Figure 1 shows a reference network. The core network is represented
by the large box in the center. It contains five core-nodes marked
represent four islands of a single network overlaid network. Only
the nodes of this network with TE links into the core network are
Swallow, et al. [Page 3]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
shown. These nodes are called edge-nodes; the terminology is in
respect to the core network, not the overlay network. Note that each
box marked "Overlay Network" could contain many other nodes. Such
nodes are not shown; they do not participate in the signalling
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
established, presumably the edge-node will inform the other nodes of
the overlay network of its existence. How this is accomplished is
beyond the scope of this document. However using a forwarding
adjacency as described in [MPLS-HIER].
In the overlay model there may be restrictions on what may be
signaled between an edge-node and a core-node. This memo addresses
the application of GMPLS to the overlay model. Specifically it
addresses RSVP procedures between an edge-node and a core-node in the
overlay model. All RSVP procedures are assumed to be identical to
[GMPLS-RSVP] except as noted in this document.
This document primarily addresses interactions between an edge-node
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
to an edge-node across a particular data plane interface. The term
core-nodes, however, refers to all nodes in the core.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Addressing
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-
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
the core-nodes as an overlay.
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
<edge-node, core-node> tuples share the same address space if the
edge-nodes in the set could establish LSPs (through the core-nodes)
among themselves (note that edge-nodes in the set may be a subset of
all the edge-nodes). The 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.
An edge-node is identified by either a single IP address representing
Swallow, et al. [Page 4]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
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
of any other addresses associated with an edge-node (i.e. addresses
which are not used in signaling connections through the GMPLS core).
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
any other edge-node to which it wishes to connect.
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
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
attached edge-node is permitted to connect.
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
latter case the connection will only be made over this interface.
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
egress' numbered TE links. In the latter case the connection will
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
edge-device.
Links may be either numbered or unnumbered. Further, links may be
bundled or unbundled. See [GMPLS-ARCH], [GMPLS-SIG], [BUNDLE], and
[RSVP-TE-UNUM].
3. ERO Processing
An edge-node MAY include an ERO. A core-node MAY reject a Path
message that contains an ERO. Such behavior is controlled by
(hopefully consistent) configuration. If a core-node rejects a Path
message due to the presence of an ERO it SHOULD return an PathErr
message with an error code of "Unknown object class" toward the
sender. This causes the path setup to fail.
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. This is to support explicit label control on the edge-
node interface, see below. If a core-node rejects a Path message due
to the presence of an ERO not of the permitted format it SHOULD
return an PathErr message with an error code of Bad Explicit Route
Object as defined in [RFC3209].
Swallow, et al. [Page 5]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
3.1. Path Message without ERO
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
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
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
available toward destination".
3.2. Path Message with ERO
When a core-node receives a Path message from an edge-node that
contains an ERO, it SHOULD verify the route against its topology
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 -
"No route available toward destination" should be returned.
3.3. Explicit Label Control
In order to support explicit label control and full identification of
the egress link an ingress edge-node may include an ERO that consists
of only the last hop. This is signaled 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
appear.
4. RRO Processing
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
remove the RRO from a Resv message before forwarding it to the edge-
node. Such behavior is controlled by (hopefully consistent)
configuration.
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
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.
Swallow, et al. [Page 6]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
5. Notification
An edge-node MAY include a NOTIFY_REQUEST object in both the Path and
Resv messages it generates. A core-node MAY remove the
NOTIFY_REQUEST object from the Path or Resv message before forwarding
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
message (either because it was not included or because it was
removed) then the core-node adjacent to the edge-node may include a
NOTIFY_REQUEST object to set its value to its own address.
6. Connection Deletion
RSVP currently deletes connections using either a single pass
PathTear message, or a ResvTear and PathTear message combination.
Upon receipt of the PathTear message, a node deletes the connection
state and forwards the message. In optical networks, however, it is
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
failed in downstream nodes (e.g., loss of frame, loss of light,
etc.). This may in turn lead to management alarms and perhaps the
triggering of restoration/protection for the connection.
To address this issue, the graceful connection deletion procedure
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
all nodes enroute of the intended deletion, prior to the actual
deletion of the connection. The procedure is described in [GMPLS-
RSVP].
7. Security Considerations
This draft imposes no new security risks over [GMPLS-RSVP]. In fact
it 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 is also permitted to restrict the actions of edge-nodes by
filtering out specific RSVP objects.
Swallow, et al. [Page 7]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
8. Acknowledgments
The authors would like to thank Kireeti Kompella, Jonathan Lang,
Dimitri Papadimitriou, Dimitrios Pendarakis and Bala Rajagopalan for
their comments and input.
9. References
9.1. Normative References
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-08.txt,
April 2002.
[GMPLS-RSVP] Ashwood-Smith, P. et. al, "Generalized MPLS - RSVP-TE
Signaling Functional Description",
draft-ietf-mpls-generalized-rsvp-te-07.txt,
April 2002.
[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
LSP Tunnels", RFC 3209, December 2001.
9.2. Informative References
[GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture", Internet Draft,
draft-ietf-ccamp-gmpls-architecture-03.txt, Aug., 2002.
[MPLS-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
MPLS TE", Internet Draft,
draft-ietf-mpls-lsp-hierarchy-08.txt, Sep., 2001.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering", Internet Draft,
draft-ietf-mpls-bundle-04.txt, July, 2002.
Swallow, et al. [Page 8]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
[RSVP-UNNUM] Kompella, K., and Rekhter, Y., "Signalling Unnumbered
Links in RSVP-TE", Internet Draft,
draft-ietf-mpls-rsvp-unnum-07.txt, July, 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
10. Authors' Addresses
<need info for other authors>
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972 3720
Email: jdrake@calient.net
Hirokazu Ishimatsu
Japan Telecom Co., Ltd.
2-9-1 Hatchobori, Chuo-ku, Tokyo, 104-0032, Japan
Tel: +81 3 5540 8493
Email: hirokazu.ishimatsu@japan-telecom.co.jp
Yakov Rekhter
Juniper Networks, Inc.
Email: yakov@juniper.net
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 497 8143
Email: swallow@cisco.com
Swallow, et al. [Page 9]
Internet Draft draft-ccamp-gmpls-overlay-00.txt January 2003
Swallow, et al. [Page 10]
