Internet Draft
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]