INTERNET DRAFT Expiration Date: February 2004 Vijayanand C HCL Technologies LDP based VPN Traffic classification draft-vijay-mpls-ldp-vpn-class-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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the use of LDP in establishing VPNs for transporting traffic that needs to be classified based on application flows. This document proposes extensions to existing LDP for establishing end-to-end VPN LSPs for transporting traffic meant for specific destination addresses and applications from specific applications. This document proposes to use a Flow FEC element, which contains the Layer 3 and transport information which is used for identifying the flow. The flow is mapped onto the appropriate VPN LSP. 1. Introduction In [BGP-MPLS-VPN], a mechanism for providing Layer 3 VPNs using MPLS with BGP for distributing labels is described. In [MARTINI-SIG], a method of establishing Layer 2 VPNs with LDP for label distribution is described. This document describes the use of LDP in establishing VPNs for carrying flows, which can be identified based on the IP and Vijayanand C [Page 1] INTERNET DRAFT LDP based VPN traffic classification September 2003 transport headers. LDP, signals separate VPN LSPs for such traffic using a Flow FEC Element. The traffic, which matches the flow parameters specified in the Flow FEC Element is mapped onto the VPN LSP and transparently carried across the MPLS domain. These VPNs, which are set up using LDP may perform traffic conditioning at the ingress for the identified flows and send the traffic through MPLS tunnels, which may guarantee bandwidth for the VPN traffic. 2. Terminology 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 [RFC-WORDS]. The reader is assumed to be familiar with the terminology in [MPLS- ARCH] and [BGP-MPLS-VPN] LSR : Label Switching Router LSP : An MPLS Label Switched Path PE : Provider edge Ingress : The LSR node which originates an LSP Egress : The LSR node which terminates an LSP VPN LSP : The LSP which is established from PE to PE by LDP described in this document Tunnel LSP : The LSP established hop by hop through the core network by mechanisms such as RSVP-TE 3. LDP Extensions A new FEC element, Flow FEC Element and a new TLV, VPN TLV are proposed in this document. The Flow FEC Element will be used in the FEC TLV of the request and mapping messages of LDP to denote the information to classify the traffic flow onto the respective VPNs. The description of the Flow FEC element and VPN TLV are stated below. The VPN TLV is similar to the target VPN attribute of [BGP- MPLS-VPN] and is used to associate sites. This is used in the Label request and Label mapping messages with the Flow FEC element. 3.1 Flow FEC Element Vijayanand C February 2004 [page 2 ] INTERNET DRAFT LDP based VPN traffic classification September 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow(TBD) | Mask | Protocol | DSCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Source Port | Maximum Source Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Destination Port | Maximum Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flow FEC element value(TBD) denoting the Flow FEC element in the FEC TLV Mask A bit mask indicating which combination of the six fields carried in this element are significant. The bit fields indicating the individual classifier fields are 00000001 : Protocol 00000010 : DSCP 00000100 : Source Port Range (minimum source port and maximum source port) 00001000 : Destination Port Range (minimum destination port and maximum destination port) 00010000 : Source Address Range (minimum source address and maximum source address) 00100000 : Destination address Range (minimum destination address and maximum destination address) 01000000 : Reserved (unused) 10000000 : Reserved (unused) Vijayanand C February 2004 [page 3 ] INTERNET DRAFT LDP based VPN traffic classification September 2003 The above-mentioned bits are OR-ed to get the final MASK value and the bit set fields in the element are significant for Flow classification. Protocol The protocol carried by IP. DSCP DiffServ code point. This is a bit field representing the diffserv service of the flow. Minimum Source Port This field indicates the minimum source port number in the range of source port numbers of the flow Maximum Source Port This field indicates the maximum source port number in the range of source port numbers of the flow Minimum Destination Port This field indicates the minimum destination port number in the range of destination port numbers of the flow Maximum Destination Port This field indicates the maximum destination port number in the range of destination port numbers of the flow Minimum Source Address This field indicates the minimum IP address in the range of source IP addresses Maximum Source Address This field indicates the maximum IP address in the range of source IP addresses Minimum Destination Address Vijayanand C February 2004 [page 4 ] INTERNET DRAFT LDP based VPN traffic classification September 2003 This field indicates the minimum IP address in the range of destination IP addresses Maximum Destination Address This field indicates the maximum IP address in the range of destination IP addresses The Flow FEC Element thus denotes the 6 tuple to be used for associating traffic onto the particular VPN. The Mask identifies which of the six fields are to be used. For instance, a Mask value of 0x15( bit fields : 00010101 ) indicates that the protocol, Source port range and Source address range are relevant. The six tuple classifier element described above is designed to be compatible with the FTN classifier described in [FTN-MIB]. 3.2 VPN TLV The VPN TLV is described below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |00| Type( TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Attribute (contd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length The Length contains the length of the VPN attribute field in bytes. The Length is always 6. Vijayanand C February 2004 [page 5 ] INTERNET DRAFT LDP based VPN traffic classification September 2003 VPN Attribute The attribute used to associate a set of sites . 4. Operational overview This section details the operation of the scheme proposed in this document 4.1 LDP signaling LDP[LDP] remote peering session is established between PEs which would like to set up the VPN. LDP working in Downstream Unsolicited Ordered control and conservative label retention mode may be used. The downstream LDP sends a Label mapping with the Flow FEC Element and VPN TLV to its upstream LDP peer PE signaling it to use the six tuple classification denoted in the Flow FEC Element to classify traffic onto the VPN associated by the VPN Attribute. The label sent in the Label TLV of the Label mapping message denotes the VPN label. The ingress PE LDP entity processes the Label mapping message as follows. If it does not recognize the Flow FEC Element it MUST send a Notification message with the "Unknown FEC" status code described in [LDP]. If the ingress does not recognize the VPN TLV it must send a notification with the "Unknown TLV" status code defined in [LDP]. Otherwise the Ingress installs a Label mapping with the classifier parameters received in the Flow FEC Element for the VPN associated by the VPN TLV. The Label mapping message may also be rejected due to standard LDP error conditions as detailed in [LDP]. LDP may also be used in Downstream On demand mode with ordered control and conservative label retention mode. In this case, a Label request message is sent with the Flow FEC Element and VPN TLV to which the downstream PE LDP peer responds with the Label mapping message described above. The LDP peer receiving the Label request should respond with "Unknown FEC" status code defined in [LDP] in the notification if it does not recognize the Flow FEC Element. Similarly if the VPN TLV is not recognized, an "Unknown TLV" notification defined in [LDP] must be sent to the ingress by the egress PE. The Label request can also be rejected due to standard LDP error conditions as detailed in [LDP]. The downstream LDP while allocating the label must ensure that it can properly interpret the label when received in the data stream from the upstream peer and direct it onto the appropriate site. Vijayanand C February 2004 [page 6 ] INTERNET DRAFT LDP based VPN traffic classification September 2003 The upstream LDP on successful receipt of the Label mapping message must install a Label mapping with the associated classifier entry containing the classifier data received in the Flow FEC Element. It should also take care to associate the VPN LSP with the appropriate tunnel LSP. The tunnel LSP is responsible for transporting the packet across the MPLS domain. It may be a TE LSP whose bandwidth can be used by the VPN LSP and it bears no inheritance in terms of VPN label parameters like EXP bits and TTL value. The flow classification which has already been signaled can be changed as follows in the Downstream Unsolicited mode. The egress PE sends a label withdraw message with the FEC element, VPN TLV and the label. The ingress must respond with a Label release message. Subsequently, the egress PE must send a Label mapping message with the FEC element containing the new flow parameters, the VPN TLV containing the same VPN attribute and the label, which may be the same. The earlier VPN LSP is thus, torn down and a new VPN LSP is established for changing the FEC flow parameters. 4.2 Forwarding The ingress LER receiving IP datagrams over interfaces configured to support the VPN, must look up the classifier table for a match of the classifier parameters. If the parameters in the datagram match with the classifier information the associated label must be pushed into the packet as the bottom of the label stack. The VRF tables described in [BGP-MPLS-VPN] and the internet routing tables may be subsequently looked up if the traffic flow does not match the classifier information. Subsequently, to forward the packet across the MPLS domain more labels may be pushed onto the label stack. Typically, the tunnel label appears on top of the label stack. The ingress LER may also perform admission control for the VPN LSP if the VPN LSP is configured to perform traffic conditioning for the VPN flow. This may be a local configuration at the ingress. After the bottom label is pushed onto the label stack the top label corresponding to the tunnel to be used across the MPLS domain is also pushed. 5. Interoperability Considerations The feature described in this document would be operational only if both the PE routers support the LDP extension described above. If one of them does not support the LDP extensions then the un- supporting PE may return appropriate advisory Notification messages. 7. Open Issues and Future Work Vijayanand C February 2004 [page 7 ] INTERNET DRAFT LDP based VPN traffic classification September 2003 In addition to the parameters described in the Flow FEC Element, additional parameters to further identify the flow more accurately may be needed. The flow identified may need traffic conditioning at the ingress PE in which case further additions to signal the bandwidth constraints may also be needed. The Tunnel LSP to be used by the PE to forward traffic across the MPLS backbone is a local decision at the ingress PE. The ingress may take into consideration among other factors security and bandwidth availability in the tunnel LSPs to choose a tunnel LSP. 8. Acknowledgements The mechanism described in this document has been inspired by literature about MPLS VPN mechanisms. Specifically the drafts authored by Martini, Eric Rosen and Yakhov Rekhter have provided motivation to come up with this contribution. The review comments and suggestions given by Prabakaran TS for this work were helpful. The support given by other well-wishers and friends during this work are recalled with gratitude. 9. Authors Address Vijayanand C HCL Technologies Limited Technologies Division No.184, NSK Road, Vadapalani, Chennai - 600 026, India Phone : +91-44-23728366 Ext: 1321 Email : vijayc@ctd.hcltech.com 10. References [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, " LDP Specification ",RFC3036, January 2001 [RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin ,"Resource ReSerVation Protocol (RSVP)",RFC2205 , September 1997 [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan , G. Swallow ," RSVP-TE: Extensions to RSVP for LSP Tunnels ",RFC 3209,December 2001. [BGP-MPLS-VPN] E. Rosen, Y. Rekhter, ôBGP/MPLS VPNsö,RFC2547, March 1999. Vijayanand C February 2004 [page 8 ] INTERNET DRAFT LDP based VPN traffic classification September 2003 [MARTINI-SIG] Luca Martini, Nasser El-Aawar, Eric C. Rosen,ö Pseudowire Setup and Maintenance using LDPö, draft-ietf-pwe3- control-protocol-03.txt, June 2003. [FTN-MIB] Thomas D. Nadeau, Cheenu Srinivasan, Arun Viswanathan,ö Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Baseö, draft-ietf-mpls-ftn-mib-08.txt, August 2003. [MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 [FA-LSP] Kireeti Kompella, Yakov Rekhter,"LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March2002. [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. Vijayanand C February 2004 [page 9 ]