Internet Draft Patty Houlik Expires: September, 2000 Zhaohui Zhang draft-zhang-crldp-ext-for-vpn-00.txt Unisphere Solutions Srinivasan Balaji GlobeSpan, Inc. Extensions to CR-LDP for VPNs 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 obsolete 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 proposes to add an optional VPN-ID TLV to CR-LDP label request message to identify the VPN that the request is meant for. Zhang, et. al. Expires September, 2000 [Page 1]
^L Internet Draft draft-zhang-crldp-ext-for-vpn-00.txt March 2000 1. Introduction One flavor of IP based VPN is to establish VPN specific tunnels among Provider Edge routers and treat the tunnels as interfaces in the VPN. For example, between a pair of Provider Edge routers, one pair of MPLS tunnels of opposite directions can be created for each VPN that the pair of PEs serve. The pair of tunnels can be treated as a virtual interface and existing routing protocols can run over it for the VPN without any modification. The MPLS VPN tunnels are usually stacked over a pair of core MPLS tunnels (level 1) between the two PEs, so that the core would not be overwhelmed by VPN tunnels ( VPN tunnels directly in core would also work, but would not scale). To establish the level 2 VPN tunnels using CR-LDP, a targeted session is established between the two PEs. The addresses of the two peers are in the core routing space. The problem is that when a targeted PE gets a label request for a tunnel for a VPN, it needs to know which VPN the label request is for. 2. Proposal We propose to add a VPN-ID TLV to CR-LDP label request message to identify the particular VPN that the LSP tunnel serves. Per configuration or other means the targeted PE knows that it needs to serve certain VPNs. If the VPN specified in the VPN-ID TLV is to be served by the targeted PE, then it returns a label and associates the label with the VPN. When an upstream router gets the label mapping message, the mandatory "Label Request Message ID TLV" is used to locate the matching label request message, so VPN-ID TLV is not needed in label mapping messages. Later when the targeted PE receives a VPN packet over the level 1 tunnel, it pops the level 1 label, and uses the level 2 label to direct the packet to the corresponding VPN. Zhang, et. al. Expires September, 2000 [Page 2]
^L Internet Draft draft-zhang-crldp-ext-for-vpn-00.txt March 2000 The VPN-ID TLV has the following format: 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 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |0|0| 0x??? | Length | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Reserved | VPN ID - OUI part | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | VPN ID - index part | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Type VPN-ID TLV type 0x??? - to be assigned Length Specifies the length of the value field - 8 bytes Reserved Reserved. Must be 0 on transmitting and ignored on receiving. Value 7-octet VPN-ID as specified in RFC2685. Another flavor of IP based VPN is BGP/VPN as explained in RFC2547, in which a VPN is not identified by VPN-ID. For easier inter-operation with the BGP based VPNs, a similar TLV can be added to CR-LDP in the future. 3. Identify pairing tunnels To run today's routing protocols over the VPN tunnels, a PE needs to pair a tunnel to another PE with the reverse direction tunnel from that PE to itself. For example, PE1, PE2, and PE3 established tunnels to each other for a particular VPN. PE1 needs to pair the tunnel PE1-->PE2 with tunnel PE2-->PE1 but not with tunnel PE3-->PE1. Since the mandatory LSPID TLV in label request messages includes "Ingress LSR Router ID" that could be any of the ingress router's IPv4 address, the pairing can be easily achieved - if the "Ingress LSR Router ID" of an incoming tunnel matches the destination of an outgoing tunnel and both tunnels are for the same VPN, then they are a pair and can be associated with the virtual interface for the VPN between the two PEs. Zhang, et. al. Expires September, 2000 [Page 3]
^L Internet Draft draft-zhang-crldp-ext-for-vpn-00.txt March 2000 If the tunnels are created per configuration (as opposed of automatically when VPN member information is learned), the source PE could optionally set a bit (say, a new R-bit next to ActFlg in the following LSPID TLV coding) in the currently reserved field of the LSPID TLV to request the targeted PE to establish the reverse direction tunnel automatically. That way the tunnel configuration is needed on only half of the PEs. 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 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |0|0| LSPID-TLV (0x0821) | Length | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Reserved |R|ActFlg | Local CR-LSP ID | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Ingress LSR Router ID | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The R-bit may not be set in modify requests [4]. If it is set, it indicates that the originator wants the targeted LSR to modify the reverse direction LSP as well. 4. RSVP considerations The same concept applies when RSVP-TE is used to set up the tunnel. The sender address in PATH messages can be used to pair the tunnels. A new object should be added to hold the VPN-ID, and the R-bit could be put into the session object. 5. Acknowledgements This document contains ideas from Kurt Melden, Eric Peterson in Unisphere Solutions, Inc. When reviewing VPN related internet drafts, we noticed that the VPN framework draft [3] also mentioned including VPN-ID in tunnel establishment signaling protocol. This new draft serves as an effort to push the ideas through by standardizing the specific encoding and discussing some related issues. 6. References [1] Jamoussi, et. al., Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr-ldp-03.txt, work in progress [2] Awduche, et. al., Extensions to RSVP for LSP Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, work in progress [3] Gleeson, et. al., A Framework for IP Based Virtual Private Networks, draft-gleeson-vpn-framework-03.txt, work in progress [4] Ash, et. al., LSP Modification Using CR-LDP, draft-ietf-mpls-crlsp-modify-01.txt, work in progress [5] Fox, et. al., Virtual Private Networks Identifier, RFC 2685 Zhang, et. al. Expires September, 2000 [Page 4]
^L Internet Draft draft-zhang-crldp-ext-for-vpn-00.txt March 2000 Author's Addresses Patty Houlik Unisphere Solutions, Inc. 5 Carlisle Road Westford, MA 01886 Voice: +1 978 614 5172 Email: phoulik@unispheresolutions.com Zhaohui Zhang Unisphere Solutions, Inc. 5 Carlisle Road Westford, MA 01886 Voice: +1 978 614 5307 Email: zzhang@unispheresolutions.com Srinivasan Balaji GlobeSpan, Inc. 1000 Route 9 North, Suite #304 Woodbridge, NJ 07095 Voice: +1 732 283 2770 Email: sbalaji@globespan.net Zhang, et. al. Expires September, 2000 [Page 5]