diff options
Diffstat (limited to 'doc/rfc/rfc4208.txt')
| -rw-r--r-- | doc/rfc/rfc4208.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc4208.txt b/doc/rfc/rfc4208.txt new file mode 100644 index 0000000..e1173a9 --- /dev/null +++ b/doc/rfc/rfc4208.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group G. Swallow +Request for Comments: 4208 Cisco Systems, Inc +Category: Standards Track J. Drake + Boeing + H. Ishimatsu + G1M Co., Ltd. + Y. Rekhter + Juniper Networks, Inc + October 2005 + + + Generalized Multiprotocol Label Switching (GMPLS) + User-Network Interface (UNI): + Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) + Support for the Overlay Model + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Generalized Multiprotocol Label Switching (GMPLS) defines both + routing and signaling protocols for the creation of Label Switched + Paths (LSPs) in various switching 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. Standards Track [Page 1] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. GMPLS User-Network Interface (GMPLS UNI) ...................4 + 2. Addressing ......................................................5 + 3. ERO Processing ..................................................6 + 3.1. Path Message without ERO ...................................6 + 3.2. Path Message with ERO ......................................6 + 3.3. Explicit Label Control .....................................7 + 4. RRO Processing ..................................................7 + 5. Notification ....................................................7 + 6. Connection Deletion .............................................8 + 6.1. Alarm-Free Connection Deletion .............................8 + 6.2. Connection Deletion with PathErr ...........................8 + 7. VPN Connections .................................................9 + 8. Security Considerations ........................................10 + 9. Acknowledgments ................................................10 + 10. References ....................................................10 + 10.1. Normative References .....................................10 + 10.2. Informational References .................................10 + +1. Introduction + + Generalized Multiprotocol Label Switching (GMPLS) 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. + + + + + + + + + + + + + + + +Swallow, et al. Standards Track [Page 2] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + + 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 + 'CN'. The four boxes around the edge marked "Overlay Network" + represent four islands of a single overlay network. Only the nodes + of this network with TE links into the core network are 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 directly in the signaling described in + this document. Only the edge-nodes can signal to set up links across + the core to other edge-nodes. + + How a link between edge-nodes is requested and triggered is out of + the scope of this document, as is precisely how that link is used by + the Overlay Network. One possibility 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. + + + + +Swallow, et al. Standards Track [Page 3] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + + 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-TE procedures between an edge-node and a core-node in + the overlay model. All signaling procedures are identical to the + GMPLS extensions specified in [RFC3473], 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; out-of-band and + non-adjacent signaling capabilities may mean that signaling messages + are delivered on a longer path. Except where noted, the term core- + node refers to the node immediately adjacent to an edge-node across a + particular data plane interface. The term core-nodes, however, + refers to all nodes in the core. + + Realization of a single or multiple instance of the UNI is + implementation dependent at both the CN and EN so long as it meets + the functional requirements for robustness, security, and privacy + detailed in Section 7. + + 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]. + + Readers are assumed to be familiar with the terminology introduced in + [RFC3031], [GMPLS-ARCH], and [RFC3471]. + +1.1. GMPLS User-Network Interface (GMPLS UNI) + + One can apply the GMPLS Overlay model at the User-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 an EN and a 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 + + + +Swallow, et al. Standards Track [Page 4] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + + 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 + + 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 that is used by GMPLS to signal between + the edge-nodes across the core network. 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 + without address mapping or translation (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. This does not imply a mandatory 1:1 mapping + between a set of LSPs and a given addressing space. + + 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 + constitutes address space membership. + + 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 + 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 + that 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, 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 + 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. + + + +Swallow, et al. Standards Track [Page 5] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + + 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], [RFC3471], [BUNDLE], and + [RFC3477]. + +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 a PathErr + message with an error code of "Unknown object class" toward the + sender as described in [RFC3209]. This causes the path setup to + fail. + + Further, a core-node MAY accept EROs that 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 that is not of the permitted + format, it SHOULD return a PathErr message with an error code of Bad + Explicit Route Object as defined in [RFC3209]. + +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 an 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 + + + +Swallow, et al. Standards Track [Page 6] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + + viable (according to topology, currently available resources, or + 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 + + In order to support explicit label control and full identification of + the egress link, an ingress edge-node may include this information in + the ERO that it passes to its neighboring core-node. In the case + that no other ERO is supplied, this explicit control information is + 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 + 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]. + +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. + +5. Notification + + An edge-node MAY include a NOTIFY_REQUEST object in both the Path and + Resv messages it generates. Core-nodes may send Notify messages to + edge-nodes that have included the NOTIFY_REQUEST object. + + A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv + message received from an edge-node before forwarding it. + + 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. + + + +Swallow, et al. Standards Track [Page 7] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + + In either of the above cases, the 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.1. Alarm-Free Connection Deletion + + RSVP-TE 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 a Path or Resv message along the connection's path to + inform all nodes en route to the intended deletion, prior to the + actual deletion of the connection. The procedure is described in + [RFC3473]. + + If an ingress core-node receives a PathTear without having first seen + an ADMIN_STATUS object informing it that the connection is about to + be deleted, it 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 core-node next to an + edge-node MAY map between teardown using ResvTear/PathTear and + PathErr with Path_state_Removed. + + + + + + +Swallow, et al. Standards Track [Page 8] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + + 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. + + Note, however, that a core-node next to an edge-node receiving a + PathErr with Path_State_Removed from its downstream neighbor MUST NOT + retain Path state and send a ResvTear further upstream because that + would imply that Path state further downstream had also been + retained. + +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, it is + RECOMMENDED that the following procedure based on [MPLS-HIER] is + followed. + + 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 that 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 [MPLS-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. + + + + + + + + + +Swallow, et al. Standards Track [Page 9] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + +8. Security Considerations + + The trust model between the core and edge-nodes is different than the + one described in [RFC3473], as the core is permitted to hide its + topology from the edge-nodes, and the core is permitted to restrict + the actions of edge-nodes by filtering out specific RSVP objects. + +9. Acknowledgments + + The authors would like to thank Kireeti Kompella, Jonathan Lang, + Dimitri Papadimitriou, Dimitrios Pendarakis, Bala Rajagopalan, and + 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.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching + (GMPLS) Signaling Functional Description", RFC 3471, + January 2003. + + [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching + (GMPLS) Signaling Resource ReserVation Protocol-Traffic + Engineering (RSVP-TE) Extensions", RFC 3473, January + 2003. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, + V., and G. Swallow, "RSVP-TE: Extensions to RSVP for + LSP Tunnels", RFC 3209, December 2001. + +10.2. Informational References + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", RFC 3031, + January 2001. + + [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered + Links in Resource ReSerVation Protocol - Traffic + Engineering (RSVP-TE)", RFC 3477, January 2003. + + + + + +Swallow, et al. Standards Track [Page 10] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + + [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link + Bundling in MPLS Traffic Engineering (TE)", RFC 4201, + October 2005. + + [EXPLICIT] Berger, L., "GMPLS Signaling Procedure for Egress + Control", RFC 4003, February 2005. + + [GMPLS-ARCH] Mannie, E., "Generalized Multi-Protocol Label Switching + (GMPLS) Architecture", RFC 3945, October 2004. + + [MPLS-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) + Hierarchy with Generalized Multi-Protocol Label + Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, + October 2005. + + [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the + Automatically Switched Optical Network (ASON)," November + 2001 (and Revision, January 2003). For information on + the availability of this document, please see + http://www.itu.int. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Swallow, et al. Standards Track [Page 11] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + +Authors' Addresses + + George Swallow + Cisco Systems, Inc. + 1414 Massachusetts Ave, + Boxborough, MA 01719 + + Phone: +1 978 936 1398 + EMail: swallow@cisco.com + + + John Drake + Boeing Satellite Systems + 2300 East Imperial Highway + El Segundo, CA 90245 + + Phone: +1 412 370-3108 + EMail: John.E.Drake2@boeing.com + + + Hirokazu Ishimatsu + G1M Co., Ltd. + Nishinippori Start up Office 214, + 5-37-5 Nishinippori, Arakawaku, + Tokyo 116-0013, Japan + + Phone: +81 3 3891 8320 + EMail: hirokazu.ishimatsu@g1m.jp + + + Yakov Rekhter + Juniper Networks, Inc. + + EMail: yakov@juniper.net + + + + + + + + + + + + + + + + + +Swallow, et al. Standards Track [Page 12] + +RFC 4208 RSVP-TE Support for the Overlay Model October 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + 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 implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Swallow, et al. Standards Track [Page 13] + |