Internet DRAFT - draft-mpls-hpark-hybrid-forwarding
draft-mpls-hpark-hybrid-forwarding
Internet Draft Hyeon Park
draft-mpls-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
<draft-mpls-hpark-hybrid-forwarding-00.txt>
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]
<Figure 1> 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]
