Internet Draft Hyeon Park draft-hpark-hybrid-forwarding-00.txt Kyeseon Lee Expires: May 2004 Sun H. Yang Bong T. Kim ETRI October 2003 Hybrid data forwarding for Economy Class Services in MPLS Status of this Memo This document is an Internet-Draft and is subject to 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes the efficient mechanism to set up and maintain the LSP for the economy class services (called ES-LSP: Economy class Services LSP). The mechanism is to reduce the overload of MPLS networks and to continue the economy class services when the ES-LSP is failed. Park, et al. expires - May, 2004 [Page 1] Internet Draft Hybrid data forwarding October 2003 There are two parts to fulfill this mechanism. Firstly, it is to minimize the information to establish and to keep the ES-LSP. Secondly, in this mechanism, the nodes adjacent to the failure point may switch over the data packet to IP forwarding instead of MPLS label swapping. On the other hand, the adjacent nodes switch over the data packets to the label swapping of MPLS at the restoration of the failure. However, in general, the ES-LSP session is withdrawn, the ES-LSP itself is reestablished into the different route or the ES is discontinued by the ES-LSP failure[1]. Thus, for the service continuity of the failed ES-LSP, this mechanism uses the hybrid data forwarding of MPLS label swapping and IP forwarding. 1. Introduction For the Qos in MPLS networks the reliability of the LSP depends on the service priority or class. That is, the survivability of the networks is accomplished by the protection, restoration mechanisms, the queue handling mechanism in the network processor and so on. However, these may increase the overload of the overall network as well as each node and then the services may not be provided eventually in normal. To resolve this problem the existing mechanisms have proposed to increase the survivability of the premium [2] or high priority service. However, this document describes the mechanism that sets up the ES-LSP for the economy service or the low priority service and processes its own failure so that to decease the whole overload of the networks. As a result, this mechanism appliance relatively increases the survivability of the premium service or the high priority service and it will continuously preserve the ES using the IP forwarding in spite of the ES-LSP failure. To minimize the overload for the transmission of the message needed to setup and keep the ES-LSP it reduces the transport period of the KeepAlive message of the LDP. Furthermore, the reestablishment of ES-LSP is not necessary because it can offer IP forwarding of data packet to the failed span or spans on ES-LSP. To implement this mechanism the ingress node adjusts the transmission period of the KeepAlive message and sends the message according to the period at the ES-LSP establishment. At the ES-LSP failure, the nodes adjacent to the point of the failure expire the timer of KeepAlive message and do not send the Notification or Release message to the end nodes of the ES-LSP. This means that the nodes adjacent to the point of the failure periodically send Hello message to aware the failure recovery, whereas the rest nodes recognize the ES-LSP as if it is normal. The adjacent nodes switch over the data packet to the IP forwarding. When the restoration of the failure is recognized by the Hello message, the adjacent nodes switch over the data packets to the label swapping of MPLS. Park, et al. expires - May, 2004 [Page 2] Internet Draft Hybrid data forwarding October 2003 2. Procedure for the ES-LSP Set-up This section describes the procedure of ES-LSP establishment as mentioned above. The procedure is as follows and the extended FEC TLV contains the FEC element format described in Section V. Step 1. Ingress node classifies the application services from the data packet of end users for the ES-LSP (for instance, FEC Prefix Filtering). Step 2. The ingress node adds the extended FEC TLV to LDP Mapping message for the ES-LSP when the LSP of LDP set up. And the added FEC TLV (exactly, FEC element) indicates that the LSP is ES-LSP. In ingress node, the transmission period of KeepAlive message is adjusted to reduce the transmission frequency of the message. Step 3. Each node over ES-LSP sets the block/unblock flag in the ES-LSP session management table. This flag is to manage the data flow mechanism whether the current ES-LSP is kept by the label swapping of MPLS or IP forwarding. Step 4. Once the ES-LSP is set up, the ES-LSP reestablishment in the ingress node is not necessary whatever the failure occurred. So, the network may reduce the overload to reestablish the ES-LSP. 3. Procedure for the service continuity under the ES-LSP failure This section describes how the data flow through the ES-LSP of MPLS switches over to IP forwarding when the failure is occurred on a span over the ES-LSP. And it also describes how the data flow through IP forwarding switches over to the ES-LSP of MPLS when the failure is recovered. As shown in Fig. 1, ES-LSP path is ABCDE and the moment the failure is occurred between node C and D the procedure to keep the continuous data flow is as follow. Park, et al. expires - May, 2004 [Page 3] Internet Draft Hybrid data forwarding October 2003 Step 1. Node C and D detect the failure of the ES-LSP 1. Step 2. Node C and D expire the timer of KeepAlive message instead of sending the Notification or Release message to the end nodes of the ES-LSP. And then node A, B, and E recognize the ES-LSP as if it is normal. Step 3. Node C sets the flag as the block status in the session management table as mentioned Session III (after this, the data packet flow deals with IP forwarding). Step 4. Node D also sets the flag as the block status in the session management table as Step 3 above. Step 5. The ES-LSP status in node C, D is block and the data packet incoming from the end users to node C is delivered to node D by IP forwarding instead of MPLS label swapping. Node D receives the data packet from node C by IP forwarding and delivers it to node E by MPLS label swapping. The switching over to IP forwarding is able to apply to the ES-LSP in this document because IP forwarding do not guarantee the Qos. Step 6. Node C and D continually send Hello message to the neighbor to perceive the ES-LSP recovery. Step 7. When node C and D discover its neighbor and keep the session again, each node sets the flag in the session management table to unblock (data flow by MPLS label swapping). Step 8. Node C and D react the timer of the KeepAlive message and then the service of the ES-LSP is available by MPLS label swapping. [A]---[B]-----[C]-~~-[D]---[E]---> ES-LSP 1 \ / [F]
IP forwarding under the ES-LSP failure Park, et al. expires - May, 2004 [Page 4] Internet Draft Hybrid data forwarding October 2003 4. The extended FEC Element TLV New FEC elements [1]are introduced in this document to support ES-LSP. A FEC TLV containing a FEC of Element type ES-LSP (0x16) is a ES-LSP Prefix FEC TLV. A FEC TLV containing a FEC of Element type ES-LSP (0x17) is a ES-LSP Host Address FEC TLV. FEC Element Type Value type name ES-Prefix 0x16 Same value defined in [RFC3036]; See below. ES-Host Addr 0x17 Same value defined in [RFC3036]; see below. ES-LSP Prefix FEC Element value encoding: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ES-Prefix (16)| Address Family | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field. PreLen One octet unsigned integer containing the length in bits of the address prefix that follows. A length of zero indicates a prefix that matches all addresses (the default destination); in this case the Prefix itself is zero octets). Prefix An address prefix encoded according to the Address Family field, whose length, in bits, was specified in the PreLen field, padded to a byte boundary. Park, et al. expires - May, 2004 [Page 5] Internet Draft Hybrid data forwarding October 2003 ES-LSP Host Address FEC Element encoding: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ES-HostAddr(17)| Address Family | Host Addr Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Host Addr | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field. Host Addr Len Length of the Host address in octets. Host Addr An address encoded according to the Address Family field. 5. References [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas,"LDP Specification", RFC 3036, January 2001. [2] S. Blake, D. Black, et al, "An Architecture for Differentiated Services," RFC2475, December 1998. [3] M. Leelanivas, Y. Rekhter, R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol," RFC3478, February 2003. [4] F. Le Faucheur, L. Wu, et al, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services," RFC3270, May 2002. Park, et al. expires - May, 2004 [Page 6] Internet Draft Hybrid data forwarding October 2003 Author's Addresses Hyeon Park Senior Engineering Staff, ETRI, 161 Gajeong-Dong, Yuseong-Gu, Daejon, 305-350, South Korea hpark@etri.re.kr Kyeseon Lee Engineering Staff, ETRI, 161 Gajeong-Dong, Yuseong-Gu, Daejon, 305-350, South Korea seonny@etri.re.kr Sun H. Yang Project Leader, ETRI, 161 Gajeong-Dong, Yuseong-Gu, Daejon, 305-350, South Korea shyang@etri.re.kr Bong T. Kim Project Leader, ETRI, 161 Gajeong-Dong, Yuseong-Gu, Daejon, 305-350, South Korea bkim@etri.re.kr Park, et al. expires - May, 2004 [Page 7]