[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
 Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
   Internet Draft                                         Marc Lasserre
   Document: draft-lasserre-tls-mpls-00.txt               Nick Slabakov
                                                               Rob Nath
                                                    Riverstone Networks
 
   Pascal Menezes                                         Loa Andersson
   Terabeam Networks                                             Utfors
 
   Andrew Smith                                           Shahid Akhtar
   Consultant                                                     Ciena
 
   Tissa Sevenirathne                                        Pierre Lin
   Force10 Networks                                 Yipes Communication
 
   Lewis Eatherton                                       Vasile Radoaca
   Excite@Home                                          Nortel Networks
 
   Ivy Hsu
   Foundry Networks
 
 
   Expires: February 2002                                   August 2001
 
 
                    Transparent VLAN Services over MPLS
 
 
 
   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.
 
 
 
 
   Lasserre et al.                                            [Page 1]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
   Abstract
 
   This document describes a transparent virtual LAN service (VLS)
   solution over MPLS, sometimes known as Transparent LAN Services
   (TLS). VLS simulates an Ethernet virtual 802.1d bridge [6] [7] for a
   given set of users.  It delivers a layer 2 broadcast domain that is
   fully capable of learning and forwarding on Ethernet MAC addresses
   that is closed to a given set of users.  Many VLS services can be
   supported from a single PE node.
 
   Conventions
 
   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 RFC 2119
 
   Placement of this Memo in Sub-IP Area
 
   RELATED DOCUMENTS
 
   http:// search.ietf.org/internet-drafts/draft-martini-l2circuit-
   trans-mpls-06.txt
 
   http://search.ietf.org/internet-drafts/draft-martini-l2circuit-
   encap-mpls-02.txt
 
   WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK
 
   PPVPN
 
   WHY IS IT TARGETTED AT THIS WG
 
   The charter of the PPVPN WG includes L2 VPN services and this draft
   specifies a model for Ethernet L2 VPN services over MPLS.
 
   JUSTIFICATION
 
   Existing Internet drafts specify how to provide point-to-point
   Ethernet L2 VPN services over MPLS. This draft defines how
   multipoint Ethernet services can be provided.
 
 
 
 
 
 
 
 
 
 
 
 
   Lasserre et al.                                            [Page 2]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
 
   Table of Contents
 
   Status of this Memo................................................1
   Abstract...........................................................2
   Conventions........................................................2
   Table of Contents..................................................3
 
   1. Overview........................................................4
   2. Bridging Model for MPLS.........................................4
   2.1 Flooding and Forwarding........................................5
   2.2 Address Learning...............................................6
   2.3 LSP Topology...................................................6
   2.4 Loop free L2 VPN...............................................6
   2.5 L2 VPN Provisioning............................................7
   2.6 LDP Based Discovery............................................7
   3. Security Considerations.........................................8
   4. References......................................................9
   5. Author's Addresses.............................................10
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   Lasserre et al.                                            [Page 3]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
   1. Overview
 
   The following discussion applies to devices that serve as Label Edge
   Routers (LERs) on a MPLS network that is VLS capable. It will not
   discuss the behavior of transit Label Switch Routers (LSRs) that are
   considered a part of MPLS network. The MPLS network provides a
   number of Label Switch Paths (LSPs) that form the basis for
   connections between LERs attached to the same MPLS network. The
   resulting set of interconnected LERs forms a private MPLS VPN where
   each LSP is uniquely identified at each MPLS interface by a label.
 
   Ethernet has become a predominant technology initially for Local
   Area Networks (LANs) and now as an access technology, specifically
   in metropolitan networks. Ethernet ports or IEEE VLANs are dedicated
   to customers on Provider Edge (PE) routers acting as LERs. Customer
   traffic gets mapped to a specific MPLS L2 VPN by configuring L2 FECs
   based upon the input port and/or VLAN.
 
   Broadcast and multicast services are available over traditional
   LANs. MPLS does not support such services currently. Sites that
   belong to the same broadcast domain and that are connected via an
   MPLS network expect broadcast, multicast and unicast traffic to be
   forwarded to the proper location(s). This requires MAC address
   learning/aging on a per LSP basis, packet replication across LSPs
   for multicast/broadcast traffic and for flooding of unknown unicast
   destination traffic.
 
   [1] defines how to carry L2 PDUs over point-to-point MPLS LSPs. This
   document describes extensions to [1] for transporting Ethernet/802.3
   and VLAN [8] traffic across multiple sites that belong to the same
   L2 broadcast domain. Note that the same model can be applied to
   other 802.1 technologies. It describes a simple and scalable way to
   offer Virtual LAN services, including the appropriate flooding of
   Broadcast, Multicast and unknown unicast destination traffic over
   MPLS, without the need for address resolution servers or other
   external servers, as discussed in [10].
 
 
   2. Bridging Model for MPLS
 
   An MPLS interface acting as a bridge must be able to flood, forward,
   and filter bridged frames.
 
 
 
 
 
 
 
 
 
 
   Lasserre et al.                                            [Page 4]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
   +----+                                              +----+
   + C1 +---+                                      +---| C1 |
   +----+   |  ..................................  |   +----+
   Site A   |  .+----+                    +----+.  |   Site B
            +--.| PE |---- MPLS Cloud ----| PE |.--+
               .+----+         |          +----+.
               .               |                .
               .               |                .
               .             +----+             .
               .             | PE |             .
               .             +----+             .
               ..................................
                               |            ^
                             +----+         |
                             | C1 |         +-- Logical bridge
                             +----+
                             Site C
 
 
   The set of PE devices interconnected via MPLS appears as a single
   802.1d bridge/switch to customer C1. Each PE device will learn
   remote MAC addresses on LSPs (and keeps learning directly attached
   MAC addresses on customer facing ports).
 
 
   2.1 Flooding and Forwarding
 
   Flooding is performed by sending unknown unicast and multicast
   frames to all possible appropriate destinations. In the MPLS
   environment this means sending the PDU through each relevant VC LSP.
   This is accomplished by explicitly copying it to each VC LSP that is
   part of the corresponding VPN.
 
   Note that multicast frames do not necessarily have to be sent to all
   VPN members. For simplicity, the default approach of broadcasting
   multicast frames can be used. Extensions explaining how to interact
   with 802.1 GMRP protocol, IGMP snooping and static MAC multicast
   filters will be discussed in a future revision.
 
   To forward a frame, a bridge must be able to associate a destination
   MAC address with a VC LSP. It is unreasonable and perhaps impossible
   to require bridges to statically configure an association of every
   possible destination MAC address with a VC LSP. Therefore, MPLS
   bridges must provide enough information to allow an MPLS interface
   to dynamically learn about foreign destinations beyond the set of
   LSRs. To accomplish dynamic learning, a bridged PDU MUST conform to
   the encapsulation described within [1].
 
 
 
 
 
   Lasserre et al.                                            [Page 5]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
 
   2.2 Address Learning
 
   Unlike BGP VPNs [8], reachability information does not need to be
   advertised and distributed via a control plane.  Reachability is
   obtained by standard learning bridge functions in the data plane.
 
   Since VC LSPs are uni-directional, two LSPs of opposite directions
   are required to form a logical bi-directional link. When a new MAC
   address is learned on an inbound LSP, it needs to be associated with
   the outbound LSP that is part of the same pair. The state of this
   logical link can be considered as up as soon as both incoming and
   outgoing LSPs are established. Similarly, it can be considered as
   down as soon as one of these two LSPs is torn down.
 
   2.3 LSP Topology
 
   PE routers run either an IGP or an EGP between them. Tunnel LSPs
   between PE routers are therefore established along routed paths.
   Note that tunnel LSPs can also be explicitly routed. Such tunnels
   form a full mesh. Partial mesh of tunnel LSPs will be discussed in a
   future revision. VC LSPs are then mapped onto these tunnel LSPs. The
   resulting VC LSP mesh for the corresponding VPN instance has to be
   loop free.
 
   In a Ethernet based topology, since VC LSPs are not terminated at
   the CE boundary, unlike Frame Relay or ATM, it is the responsibility
   of the Service Providers to offer a loop free topology. With Frame
   Relay or ATM, it is the customers' responsibility to run STP or a
   routing protocol to prevent loops. With Ethernet as the access
   medium, a port and/or a VLAN is used per customer. Customer facing
   ports can be used to tunnel untagged or 802.1q tagged traffic. The
   VC LSPs connected to each site in the corresponding VPN are only
   visible to the PE device.
 
   2.4 Loop free L2 VPN
 
   In order to avoid running a STP instance per VPN, which would not
   scale, partial mesh configurations of VC LSPs are not allowed. Note
   that customers are allowed to run STP such as when a customer has a
   back door link used for backup. In such a case STP BPDUs are simply
   tunneled through the MPLS cloud.
 
   Each PE MUST create a rooted tree to every other PE router that
   serve the same L2 VPN. Each PE MUST support a "split-horizon" scheme
   in order to prevent loops, that is, a PE MUST NOT forward traffic
   from one VC LSP to another in the same VPN (since each PE has direct
   connectivity to all other PEs in the same VPN).
 
 
 
 
   Lasserre et al.                                            [Page 6]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
   2.5 L2 VPN Provisioning
 
   Provisioning of a full mesh can be automatic with a discovery
   protocol where each PE advertizes which VPN(s) it serves to other
   PEs in the same domain, reducing the provisioning complexity to O(1)
   PE to configure when a new site is added, and O(n) new LSPs to be
   set up.
 
   The number of sites per VPN and the number of VPNs per PE router
   define the total number of VC LSPs to be managed. Let's consider for
   example that each VPN has an average of 4 sites and that 1000
   customers are supported in a PE, 4000 VC LSPs need to be established
   and maintained. Since VC LSPs are set up via LDP, there is no need
   to refresh LSP states like in the RSVP case. Tunnel LSPs can be
   either be established via LDP or via RSVP.
 
   Since LDP is required for establishing VC LSPs, LDP is a logical
   choice to exchange VPN membership between PE routers. BGP offers the
   advantage of being able to set up inter-provider VPNs. However, BGP
   is typically not enabled on PE routers, but only on core routers.
 
   The signaling of VPN membership via BGP will be discussed in a
   future revision. A possible method for exchanging VPN membership via
   BGP can be based on [5].
 
   2.6 LDP Based Discovery
 
   Once an LDP adjacency has been formed between two PEs, all VC LSPs
   get established over this single TCP session.
 
   Directly connected PEs multicast LDP hellos periodically. Non-
   directly connected PEs exchanged unicast targeted hellos to each
   desired peer. Once a hello adjacency is formed, a LDP TCP connection
   is established. A LDP session is established over this connection by
   exchanging LDP initialization messages.
 
   IGP extensions to automatically discover VLS capable PEs can be
   used, such as defined in [4]. This will allow a TLS capable PE node
   to automatically setup a LDP adjacency to the discovered node and
   automate provisioning for VC LSPs.  If LDP is used to create tunnel
   LSPs, then this will be automated once the newly discovered TLS PE
   node has an IP entry in the IGP (this assumes that a loopback
   address is used to represent the newly discovered TLS capable PE
   node). However if RSVP-TE is used for the tunnel LSP, then it is
   important that the two PE nodes have a tunnel LSP between them (the
   means of doing this is beyond the scope of this document).
 
   In [2], the L2 VPN information is carried in a Label Mapping message
   sent in downstream unsolicited mode. This document defines a new
 
 
 
   Lasserre et al.                                            [Page 7]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
   parameter id, a 7-byte VPN Id as defined in [9], to the interface
   parameters field in the VC FEC described in [2].
 
 
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Parameter ID |    Length     |    Variable Length Value      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Variable Length Value                 |
      |                             "                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
   The parameter ID is defined as follows:
      Parameter   ID Length    Description
 
          0x01         4       Interface MTU in octets.
          0x02         4       Maximum Number of concatenated ATM
   cells.
          0x03   up to 82      Optional Interface Description string.
          0x04         4       CEM [8] Payload Bytes.
          0x05         4       CEM options.
          0x06         7       VPN Id.
 
   The first five parameters are as described in [2].
 
   The VPN Id field is a unique 7-byte number that identifies a
   specific L2 VPN instance in a service provider network. All VLS
   capable PE nodes MUST use the same VPN ID for a given L2 VPN. PE
   nodes belonging to the same VLS must be capable of mapping Ethernet
   ports and/or VLANs to the corresponding VPN Id.
 
   3. Security Considerations
 
   This document does not affect the underlying security issues of
   MPLS.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   Lasserre et al.                                            [Page 8]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
 
   4. References
 
   [1] "Encapsulation Methods for Transport of Layer 2 Frames Over
   MPLS", draft-martini-l2circuit-encap-mpls-02.txt (Work in progress)
 
   [2] "Transport of Layer 2 Frames Over MPLS", draft-martini-
   l2circuit-trans-mpls-06.txt (Work in progress)
 
   [3] "LAN Emulation over ATM version 1.0", af-lane-0021.0000 (ATM
   Forum)
 
   [4] "Distribution of 802.1Q VLAN information using Opaque LSA",
   draft-tsenevir-8021qospf-00.txt (Work in progress)
 
   [5] "Use of BGP-MP for Layer 2 VPN Membership discovery", draft-
   tsenevir-bgp-l2vpn-00.txt (Work in progress)
 
   [6] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC
   Bridges".
 
   [7] 802.1D - "Information technology - Telecommunications and
   information exchange between systems - Local and metropolitan area
   networks - Common specifications - Part 3: Media Access Control
   (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993,
   802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and
   P802.12e." ISO/IEC 15802-3: 1998.
 
   [8] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE Standards
   for Local and Metropolitan Area Networks: Virtual Bridged Local Area
   Networks", July 1998.
 
   [9] Fox, Gleeson, "Virtual Private Networks Identifier", RFC2685
 
   [10] "Requirements for Network Based Layer 2 VPN", draft-tsenevir-
   l2-req-00.txt (Work in progress)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   Lasserre et al.                                            [Page 9]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
   5. Author's Addresses
 
   Marc Lasserre
   Riverstone Networks
   5200 Great America Pkwy      Phone:  1-408-878-6550
   Santa Clara, CA 95054        Email:  marc@riverstonenet.com
 
   Nick Slabakov
   Riverstone Networks
   5200 Great America Pkwy      Phone:  1-303-471-6926
   Santa Clara, CA 95054        Email:  nslabakov@riverstonenet.com
 
   Rob Nath
   Riverstone Networks
   5200 Great America Pkwy      Phone:  1-408-878-6742
   Santa Clara, CA 95054        Email:  rnath@riverstonenet.com
 
   Loa Andersson
   Utfors Bredband AB           Phone: +46 8 5270 50 38
   Rasundavagen 12 169 29 Solna Email: loa.andersson@utfors.se
 
   Pascal Menezes
   TeraBeam Networks
   2300 Seventh Ave
   Seattle, WA 98121            Email: Pascal.Menezes@Terabeam.com
 
   Andrew Smith                 Fax: +1 415 345 1827
   Consultant                   Email: ah_smith@pacbell.net
 
   Tissa Senevirathne
   Force10 Networks
   1440 McCarthy Blvd           Phone: 408-865-5103
   Milpitas, CA                 Email: tsenevir@hotmail.com
 
   Pierre Lin
   Yipes Communication
   114 Sansome St               Phone: 415-218-9520
   San Francisco, CA 94104      Email: pierre.lin@yipes.com
 
   Lewis Eatherton
   Excite@Home
   450 Broadway Street          Phone: 650-556-5022
   Redwood City, CA 94063       Email: leathert@excitehome.net
 
   Vasile Radoaca
   Nortel Networks
   600 Technology Park          Phone: 978-288-6097
   Billerica MA 01821           Email: vasile@nortelnetworks.com
 
   Ivy Hsu
 
 
 
   Lasserre et al.                                           [Page 10]


   Internet Draft   draft-lasserre-tls-mpls-00.txt         August 2001
 
 
   Foundry Networks
   2100 Gold Street
   PO Box 649100                Phone: 408-586-1795
   San Jose, CA 95164           Email: ihsu@foundrynet.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   Lasserre et al.                                           [Page 11]