[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

        Provider Provisioned VPN WG                     Hamid Ould-Brahim
        Internet Draft                                    Nortel Networks
        Expiration Date: November 2004
                                                             Yakov Rekhter
                                                         Juniper Networks
     
                                                                 (Editors)
     
                                                                 May 2004
     
                                GVPN Services:
                        Generalized VPN Services using
                             BGP and GMPLS Toolkit
     
                  draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt
     
     
     
     
     
     Status of this Memo
     
        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026 [RFC-2026], except
        that the right to produce derivative works is not granted.
     
        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 draft describes a suite of port-based Provider-provisioned
        VPN services called Generalized VPNs (GVPNs) that uses BGP as a
        VPN auto-discovery and GMPLS as a signaling mechanism. GVPN
        services are "generalized" as the interfaces on the customer’s
        and provider ports could be any of the interfaces supported by
        Generalized MPLS (GMPLS). GVPN services outlined in this
        document are: (1) a port-based Generalized Virtual Private Wire
        (GVPW) where the basic unit of service is a Label Switched Path
     
     Ould-Brahim, Rekhter             November 2004            [Page 1]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        (LSP) between a pair of customer’s ports within a given VPN
        port-topology. (2) a Generalized Virtual Private Cross-connect
        (GVPXC) service where the service provider network appears to
        the customer network as a GMPLS-enabled Virtual Private node. A
        GVPXC service provides flexible traffic engineering on the
        client network and eliminates the need for n square routing
        peering between CEs. Since GVPNs uses GMPLS as the signaling
        mechanism, and since GMPLS applies to both TDM and Optical
        interfaces, it results that GVPN services include Optical/TDM
        VPNs (though they need not be restricted to).
     
     
     
     
     Original Contributors of the initial versions of this document:
     
     
        Hamid Ould-Brahim (Nortel)
        Yakov Rekhter (Juniper)
        Luyuan Fang (AT&T)
        Don Fedyk (Nortel)
        Peter Ashwood-Smith (Nortel)
        Eric C. Rosen (Cisco)
        Eric Mannie (KPN Qwest)
        John Drake (Calient Neworks)
        Yong Xue (Worldcomm/UUNET)
        Riad Hartani (Caspian Networks)
        Dimitri Papadimitrio (Alcatel)
        Lou Berger (Movaz)
     
     
     1. Generalized VPN Services
     
     
        Consider a service provider network that consists of devices
        that supports Generalized MPLS (e.g., Optical Cross Connect,
        SDH Cross Connect, etc…). We partition these devices into P
        (provider) and PE (provider edge) nodes (in the context of this
        document we’ll refer to these devices as just "PE"). The P
        nodes are connected only to the nodes within the provider’s
        network (in the context of this document we’ll refer to these
        devices as just "P"). The PEs are connected to the other nodes
        within the provider network (either Ps, or PEs), as well as to
        the devices outside of the provider network. We’ll refer to
        such other devices as Client Edge Devices (CEs). An example of
        a CE would be a router, or an SDH cross-connect, or an Ethernet
        switch.
     
     
     
     
     
     
     Ould-Brahim & Rekhter.      November 2004                    [Page 2]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
                                +---+    +---+
                                | P |    | P |
                                +---+    +---+
                          PE   /              \  PE
                       +-----+               +-----+    +--+
                       |     |               |     |----|  |
               +--+    |     |               |     |    |CE|
               |CE|----+-----+               |     |----|  |
               +--+\      |                  |     |    +--+
                    \  +-----+               |     |
                     \ |     |               |     |    +--+
                      \|     |               |     |----|CE|
                       +-----+               +-----+    +--+
                              \              /
                              +---+    +---+
                              | P |....| P |
                              +---+    +---+
     
        Figure 1: Generalized Port-Based VPN Reference Model
     
        We define a "Generalized VPN" service as a Provider-provisioned
        VPN service that uses BGP as a VPN auto-discovery and GMPLS as
        a signaling and routing mechanisms. GVPN services are
        "generalized" as the interfaces on the customer’s and provider
        ports could be any of the interfaces supported by Generalized
        MPLS (GMPLS). Since GVPN uses GMPLS as the signaling mechanism,
        and since GMPLS applies to both TDM and Optical interfaces, it
        results that GVPN services includes Optical/TDM VPNs (though
        they need not be restricted to). Note that this draft assumes
        that (1) GMPLS is used as a signaling both within the service
        provider, as well as between the customer and the service
        provider; (2) GMPLS is used not just as a signaling mechanism,
        but as a routing mechanism within the provider network and for
        services such as generalized virtual private cross-connect.
     
        A CE is connected to a PE via one or more links. In the context
        of this document a link is the same as a GMPLS Traffic
        Engineering (TE) link construct, as defined in [GMPLS-ROUTING].
        In the context of this document a link is a logical construct
        that is used to represent grouping on a per VPN basis of
        physical resources used to connect a CE to a PE. Interfaces at
        the end of each link could be any of the interfaces that are
        supported by GMPLS. Likewise, CEs and PEs could be any devices
        that are supported by GMPLS (e.g, optical cross connects, SDH
        cross-connects, LSRs, etc).
     
        Each link may consist of one or more channels or sub-channels
        (e.g., wavelength or wavelength and timeslot respectively). For
        purpose of this discussion we assume that all the channels
        within a given link have shared similar characteristics (e.g.,
        bandwidth, encoding, etc_), and can be interchanged from the
        CEs point of view. Channels on different links of a CE need not
        have the same characteristics.
     
     Ould-Brahim & Rekhter.      November 2004                    [Page 3]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        There may be more than one link between a given CE PE pair. A
        CE may be connected to more than one PE (with at least one port
        per each PE). And, of course, a PE may have more than one CE
        connected to it.
     
        If a CE is connected to a PE via multiple links and all these
        links belong to the same VPN, then for the purpose of  this
        document these links could be treated as a single link using
        the link bundling constructs [LINK-BUNDLING].
     
        In general a link may have only data bearing channels, or only
        control bearing channels, or both.  For the purpose of this
        discussion we assume that for a given CE-PE pair at least one
        of the links between them has at least one data bearing
        channel, and at least one control bearing channel, or there is
        an IP connectivity between the CE and the PE that could be used
        for exchanging control information (more on this in Section 4).
     
        A link has two end-points - one on CE and one on PE. In the
        context of this document we'll refer to the former as "CE
        port", and to the latter as "PE port". From the above it
        follows that a CE is connected to a PE via one or more ports,
        where each port may consists of one or more channels or sub-
        channels (e.g., wavelength or wavelength and timeslot
        respectively), and all the channels within a given port have
        shared similar characteristics (e.g., bandwidth, encoding,
        etc_), and can be interchanged from the CEs point of view.
        Channels on different ports of a CE need not have the same
        characteristics. Just like links, in the context of this
        document ports are logical construct that
        are used to represent grouping of physical resources on a per
        GVPN basis that are used to connect a CE to a PE.
     
        At any given point in time, a given port on a PE is associated
        with at most one GVPN, or to be more precise with at most one
        Port Information Table (although different ports on a given PE
        could be associated with different GVPNs, or to be more precise
        with different Port Information Tables). This association is
        established and maintained by the service provider provisioning
        system.
     
        This document assumes that the interface between the CE and PE
        used for the purpose of signaling is based on GMPLS protocols
        [GMPLS-RSVP-TE] and follows the procedures described in [GMPLS-
        OVERLAY].
     
     1.1 Addressing, Ports, Links, and Control Channels
     
        This document assumes that within a given GVPN each port on a
        CE that connects the CE to a PE has an identifier that is
        unique within that GVPN (but need not be unique across several
        GVPNs). One way to accomplish this is to assign each port an IP
        address that is unique within a given GVPN, and use this
     Ould-Brahim & Rekhter.      November 2004                    [Page 4]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        address as a port identifier. Another way to accomplish this is
        to assigned each port on a CE an index that is unique within
        that CE, assign each CE an IP address that is unique within a
        given GVPN, and then use a tuple <port index, CE IP address> as
        a port identifier.
     
        This document assumes that within a service provider network,
        each port on a PE has an identifier that is unique within that
        network. One way to accomplish this would be to assign each
        port on a PE an index that is unique within that PE, assign
        each PE an IP address that is unique within the service
        provider network (in the case of multi-provider operations, the
        address has to be unique across all the providers involved),
        and then use a tuple <port index, PE IP address> as a port
        identifier within the provider network.
     
        As a result, each link connecting the CE to the PE is
        associated with a CE port that has a unique identifier within a
        given GVPN, and with a PE port that has a unique identifier
        within the service provider network. We'll refer to the former
        as the customer port identifier (CPI), and to the latter as the
        provider port identifier (PPI).
     
        This document assumes that in addition to PPI, each port on PE
        has also an identifier that is unique within the GVPN of that
        port.  One way to accomplish this is to assign each port an IP
        address that is unique within a given GVPN, and use this
        address as a port identifier. Another way to accomplish this is
        to assign each port an index that is unique within a given PE,
        assign each PE an IP address that is unique within a given GVPN
        (but need not be unique within the service provider network),
        and then use a tuple <port index, PE IP address> acts as a port
        identifier.  We'll refer to such port identifier as VPN-PPI.
        Note that PE IP address used for VPN-PPI need not be the same
        as PE IP address used for PPI. If for a given port on a PE its
        PPI and VPN-PPI are both unnumbered, then they both could use
        exactly the same port index.
     
        Note that IP addresses used for CPIs, PPIs and VPN-PPIs could
        be either IPv4 or IPv6 addresses.
     
        For a given link connecting a CE to a PE, if CPI is an IP
        address, then VPN-PPI has to be an IP address as well. And if
        CPI is an <port index, CPI IP address>, then VPN-PPI has to be
        an <port index, PE IP address>. However, for a given port on
        PE, whether VPN-PPI of that port is an IP address or an <port
        index, PE IP address> is independent of whether PPI of that
        port is an IP address or an <port index, PE IP address>.
     
     
     
     
     
     Ould-Brahim & Rekhter.      November 2004                    [Page 5]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        This document assumes that assignment of PPIs is controlled
        solely by the service provider (without any coordination with
        the GVPN customers), while assignment of CPIs and VPN-PPIs is
        controlled solely by the GVPN that the CPIs and VPN-PPIs belong
        to. And, of course, each GVPN could assign its CPIs and VPN-
        PPIs on its own, without any coordination with other GVPNs.
     
        This document assumes also that there is an IP control channel
        between the CE and the PE. This channel could be either a
        single IP hop, or an IP private network, or even an IP VPN.
        We’ll refer to the CE’s address of this channel as the CE
        Control Channel Address (CE-CC-Addr), and to the PE’s address
        of this channel as the PE Control Channel Address (PE-CC-Addr).
        Both CE-CC-Addr and PE-CC-Addr are required to be unique within
        the GVPN they belong to, but are not required to be unique
        across multiple GVPNs. Assignment of CE-CC-Addr and PE-CC-Addr
        are controlled by the GVPN these addresses belong to.
     
        Multiple ports on a CE could share the same control channel
        only as long as all these ports belong to the same GVPN.
        Likewise, multiple ports on a PE could share the same control
        channel only as long as all these ports belong to the same
        GVPN.
     
        An important goal of GVPN services (particularly with respect
        to GVPW and GVPXC services - see sections below) is the ability
        to support what is known as "single end provisioning", where
        addition of a new port to a given GVPN would involve
        configuration changes only on the PE that has this port and on
        the CE that is connected to the PE via this port. Another
        important goal in the GVPN service is the ability to
        establish/terminate an LSP between a pair of (existing) ports
        within a GVPN without involving configuration changes in any of
        the provider’s devices. The mechanisms outlined in this
        document aim at achieving these goals. Specifically, as part of
        the GVPN service offering, these mechanisms (1) enable the
        service provider to restrict the set of ports that a given port
        could be connected to, (2) enable the service provider to
        provide a CE with the information about the ports that the CE
        could be connected, (3) enable a CE to establish the actual LSP
        to a subset of ports provided by (2). Finally, the mechanisms
        allow different GVPN topologies to be supported ranging from
        hub-and-spoke to complete mesh.
     
     2. Port-based Generalized Virtual Private Wire (GVPW)
     
        A Generalized Virtual Private Wire (GVPW) is a port-based
        VPN service where a pair of CEs could be connected through
        the service provider network via a GMPLS-based LSP within a
        given VPN port topology. It is precisely this LSP that forms
        the basic unit of the GVPW service that the service provider
        network offers. If a port by which a CE is connected to a PE
        consists of multiple channels (e.g., multiple wavelengths), the
     
     Ould-Brahim & Rekhter.      November 2004                    [Page 6]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        CE could establish LSPs to multiple other CEs over this single
        port.
     
        The service provider does not initiate the creation of an
        LSP between a pair of PE ports. This is done rather by the
        CEs, which attach to the ports. However, the SP, by using
        the mechanisms/toolkit outlined in this document, restricts
        the set of other PE ports, which may be the remote endpoints
        of LSPs that have the given port as the local endpoint.
        Subject to these restrictions, the CE-to-CE connectivity is
        under the control of the CEs themselves. In other words, SP
        allows a GVPN to have a certain set of topologies (expressed
        as a port-to-port connectivity matrix), and CE-initiated
        signaling is used to choose a particular topology from that
        set.
     
        A PE maintains for each GVPW configured on that PE a port
        information tables (PIT) associated with each GVPW that has at
        least one port configured on a PE. A PIT contains a list of
        <CPI, PPI> tuples for all the ports within its GVPN. Note that
        a PIT may as well hold routing information (for example when
        CPIs are learnt using a routing protocol).
     
                       PE                        PE
                    +---------+             +--------------+
        +--------+  | +------+|             | +----------+ | +--------+
        |  VPN-A |  | |VPN-A ||             | |  VPN-A   | | |  VPN-A |
        |   CE1  |--| |PIT   ||  BGP route  | |  PIT     | |-|   CE2  |
        +--------+  | |      ||<----------->| |          | | +--------+
                    | +------+| Distribution| +----------+ |
                    |         |             |              |
        +--------+  | +------+|             | +----------+ | +--------+
        | VPN-B  |  | |VPN-B ||  --------   | |   VPN-B  | | |  VPN-B |
        |  CE1   |--| |PIT  ||-(   GMPLS )--| |   PIT    | |-|   CE2  |
        +--------+  | |      || (Backbone ) | |          | | +--------+
                    | +------+|  ---------  | +----------+ |
                    |         |             |              |
        +--------+  | +-----+ |             | +----------+ | +--------+
        | VPN-C  |  | |VPN-C| |             | |   VPN-C  | | |  VPN-C |
        |  CE1   |--| |PIT  | |             | |   PIT    | |-|   CE2  |
        +--------+  | |     | |             | |          | | +--------+
                    | +-----+ |             | +----------+ |
                    +---------+             +--------------+
     
                    Figure 2 Generalized Virtual Private Wire
     
     
     2.1 VPN Auto-discovery Mechanism
     
        This document assumes a BGP-based auto-discovery for supporting
        GVPW services.
     
     
     Ould-Brahim & Rekhter.      November 2004                    [Page 7]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        A PIT on a given PE is populated from two sources: the
        information related to the CEs’ ports attached to the ports on
        that PE (this information could be optionally received from the
        CEs), and the information received from other PEs. We’ll refer
        to the former as the "local" information, and to the latter as
        the "remote" information.
     
        Propagation of local information to other PEs is accomplished
        by using BGP VPN auto-discovery procedures, as specified in
        [BGP-VPN-AUTODISCOVERY]. To restrict the flow of this
        information to only the PITs within a given GVPN, we use BGP
        route filtering based on the Route Target Extended Community
        [BGP-COMM], as follows.
     
        Each PIT on a PE is configured with one or more Route Target
        Communities, called "export Route Targets", that are used for
        tagging the local information when it is exported into
        provider’s BGP. The granularity of such tagging could be as
        fine as a single <CPI, PPI> pair. In addition, each PIT on a PE
        is configured with one or more Route Target Communities, called
        "import Route Targets", that restrict the set of routes that
        could be imported from provider’s BGP into the PIT to only the
        routes that have at least of these Communities.
     
        When a service provider adds a new GVPN port to a particular
        PE, this port is associated at provisioning time with a PIT on
        that PE, and this PIT is associated (again at provisioning
        time) with that GVPN.
     
        Once a port is configured on the PE, the CE that is attached
        via this port to the PE MAY pass to the PE the CPI information
        of that port. This document assumes that this is accomplished
        by using BGP  (however, the document doesn’t preclude the use
        of other mechanisms).
     
        This information, combined with the PPI information available
        to the PE, enables the PE to create a tuple <CPI, PPI> for such
        port, and then use this tuple to populate the PIT of the GVPN
        associated with that port.
     
        In order to establish an LSP, a CE needs to identify all other
        CEs in the CE's GVPN it wants to connect to. A CE may already
        have obtained the CE list through configuration or through some
        other schemes (such schemes are outside the scope of this
        draft).
     
     
     
     
     
     
     
     Ould-Brahim & Rekhter.      November 2004                    [Page 8]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        A port, in addition to its CPI and PPI may also have other
        information associated with it that describes characteristics
        of the channels within that port, such as encoding supported by
        the channels, bandwidth of a channel, total unreserved
        bandwidth within the port, etc. This information could be
        further augmented with the information about certain
        capabilities of the Service Provider network (e.g., support
        RSOH DCC transparency, arbitrary concatenation, etc…). This
        information is used to ensure that ports at each end of an LSP
        have compatible characteristics, and that there are sufficient
        unallocated resources to establish an LSP. Distribution of this
        information (including the mechanisms for distributing this
        information) is identical to the distribution of the <CPI, PPI>
        information. Distributing changes to this information due to
        establishing/terminating of LSPs is identical to the
        distribution of the <CPI, PPI> information, except that
        thresholds should be used to contain the volume of control
        traffic caused by such distribution.
     
        It may happen that for a given pair of ports within a GVPN,
        each of the CEs connected to these ports would concurrently try
        to establish an LSP to the other CE. If having a pair of LSPs
        between a pair of ports is viewed as undesirable, the way to
        resolve this is to require the CE with the lower value of CPI
        to terminate the LSP originated by the CE. This option could be
        controlled by configuration on the CE devices.
     
     
     
     
     2.1.1 Encoding of CPI, PPI, and channel characteristics in BGP
     
        The <CPI, PPI> mapping is carried using the Multiprotocol
        Extensions BGP [RFC2858]. [RFC2858] defines the format of two
        BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be
        used to announce and withdraw the announcement of reachability
        information. We introduce a new address family identifier (AFI)
        for GVPN (to be assigned by the IANA), a new subsequent address
        family identifier (to be assigned by the IANA), and also a new
        NLRI format for carrying the CPI and PPI information.
     
        One or more <PPI, CPI> tuples could be carried in the above
        mentioned BGP attributes.
     
        The format of encoding a single <PPI, CPI> tuple is shown in
        Figure 3 below:
     
     
     
     
     
     
     Ould-Brahim & Rekhter.      November 2004                    [Page 9]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
             +---------------------------------------+
             |     Length (1 octet)                  |
             +---------------------------------------+
             |     PPI AFI (2 octets)                |
             +---------------------------------------+
             |     PPI Length (1 octet)              |
             +---------------------------------------+
             |     PPI (variable)                    |
             +---------------------------------------+
             |     CPI AFI (2 octets)                |
             +---------------------------------------+
             |     CPI (length)                      |
             +---------------------------------------+
             |     CPI (variable)                    |
             +---------------------------------------+
     
             Figure 3: NLRI BGP encoding
     
          The use and meaning of these fields are as follows:
     
              Length:
     
                 A one octet field whose value indicates the length of
             the  <PPI, CPI> Information tuple in octets.
     
              PPI AFI:
     
                A two octets field whose value indicates address
                family identifier of PPI
     
              PPI Length:
     
                A one octet field whose value indicates the length of
                of the PPI field
     
              PPI field:
     
                A variable length field that contains the value of
                the PPI (either an address or <port index,
                address> tuple
     
              CPI AFI field:
     
                A two octets field whose value indicates address
                family of the CPI.
     
              CPI Length:
     
                A once octet field whose value indicates the
                length of the CPI field.
     
              CPI (variable):
     
                A variable length field that contains the CPI
     Ould-Brahim & Rekhter.      November 2004                   [Page 10]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
        value (either an address or <port index, address> tuple.
     
     2.2 Signaling
     
        Once a CE obtains the information about the CPIs of other ports
        within the same GVPN, which we'll refer to as "target ports",
        the CE uses a (subset of) GMPLS signaling, to request the
        provider network to establish an LSP to a target port.
     
        For inter-CE connectivity, the request originated by the CE
        contains the CPI of the port on the CE that CE wants to use for
        the LSP, and the CPI of the target port. When the PE attached
        to the CE that originated the request receives the request, the
        PE identifies the appropriate PIT, and then uses the
        information in that PIT to find out the PPI associated with the
        CPI of the target port carried in the request. The PPI should
        be sufficient for the PE to establish an LSP. Ultimately the
        request reaches the CE associated with the target CPI (note
        that the request still carries the CPI of the CE that
        originated the request). If the CE associated with the target
        CPI accepts the request, the LSP is established.
     
        Note that a CE need not establish an LSP to every target port
        that CE knows about - it is a local to the CE matter to select
        a subset of target ports to which the CE will try to establish
        LSPs.
     
        When a CE sends an RSVP Path message to a PE, the source IP
        address in the IP packet that carries the message is set to the
        appropriate CE-CC-Addr, and the destination IP address in the
        packet is set to the appropriate PE-CC-Addr. When the PE sends
        back to the CE the corresponding Resv message, the source IP
        address in the IP packet that carries the message is set to the
        PE-CC-Addr, and the destination IP address is set to the CE-CC-
        Addr.
     
        Likewise, when a PE sends an RSVP Path message to a CE, the
        source IP address in the IP packet that carries the message is
        set to the appropriate PE-CC-Addr, and the destination IP
        address in the packet is set to the appropriate CE-CC-Addr.
        When the CE sends back to the PE the corresponding Resv
        message, the source IP address in the IP packet that carries
        the message is set to the CE-CC-Addr, and the destination IP
        address is set to the PE-CC-Addr.
     
        In addition to being used for IP addresses in the IP packet
        that carries RSVP messages between CE and PE, CE-CC-Addr and
        PE-CC-Addr are also used in the Next/Previous Hop Address field
        of the IF_ID RSVP_HOP object that is carried between CEs and
        PEs.
     
        In the case where a link between CE and PE is a numbered non-
        bundled link, the CPI and VPN-PPI of that link are used for the
        Type 1 or 2 TLVs of the IF_ID RSVP HOP object that is carried
     Ould-Brahim & Rekhter.      November 2004                   [Page 11]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
        between the CE and PE. In the case where a link between CE and
        PE is an unnumbered non-bundled link, the CPI and VPN-PPI of
        that link are used for the IP Address field of the Type 3 TLV.
        In the case where a link between CE and PE is a bundled link,
        the CPI and VPN-PPI of that link are used for the IP Address
        field of the Type 3 TLVs.
     
        When a CE originates a Path message to establish an LSP from a
        particular port on that CE to a particular target port the CE
        uses the CPI of its port in the Sender Template object. If the
        CPI of the target port is an IP address, then the CE uses it in
        the Session object. And if the CPI of the target port is a
        <port index, IP address> tuple, then the CE uses the IP address
        part of the tuple in the Session object, and the whole tuple as
        the Unnumbered Interface ID subobject in the ERO. When the Path
        message arrives at the ingress PE, the PE selects the PIT
        associated with the GVPN, and then uses this PIT to map CPIs
        carried in the Session and the Sender Template objects to the
        appropriate PPIs. Once the mapping is done, the ingress PE
        replaces CPIs with these PPIs. As a result, the Session and the
        Sender Template objects that are carried in the GMPLS signaling
        within the service provider network carry PPIs, and not CPIs.
        At the egress PE, the PE performs the reverse mapping – it maps
        PPIs carried in the Session and the Sender Template object into
        the appropriate CPIs, and then sends the Path message to the CE
        that has the target port.
     
     2.3 GVPW Routing Considerations
     
        It is also desirable, that the service provider, as a value
        added service, may provide to a GVPW-based CE with a list of
        ports on all other CEs  that belong to the same VPN. This is
        accomplished by passing the information stored in the PE PITs
        to the attached CE. A way to accomplish this is by using BGP
        Multi-protocol extensions (however this draft doesn't preclude
        other mechanisms to be used). Although optional, this draft
        recommends the PE to signal to the attached CEs the remote CPIs
        it learnt from the remote CEs part of the same GVPN. A CE may
        decide to initiate an LSP setup request to a remote CE only
        when it learns the CPI of the remote CE from the PE. This has
        the benefit to avoid rejecting LSP setup request while the PE
        is populating the PITs.
     3. Generalized Virtual Private Cross-Connect (GVPXC)
     
        A GVPXC is a GVPN service where the service provider network
        appears as a virtual private cross-connect. A GVPXC operates
        similarly to a physical optical cross-connect except that it
        applies to GMPLS-based interfaces and allows a wide spectrum of
        port topology such as hub and spoke, full mesh, and arbitrary
        topologies. The GVPXC port topology is defined by the customer,
        and enforced by the service provider. Customers can signal any
        inter-port connectivity according to the topology implemented by
        the VPOXC. Client devices operate within the VPOXC space
        independently from the service provider network operations.
     Ould-Brahim & Rekhter.      November 2004                   [Page 12]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
     
     
     
                               GVPXC
                  +-------------------------------+
                  |          +---+    +---+       |
                  |          | P |....| P |       |
                  |          +---+    +---+       |
                  |    PE  /              \  PE   |
                  | +-----+               +-----+ |  +--+
                  | |     |               |     |-|--|  |
            +--+  | |     |               |     | |  |CE|
            |CE|--|-+-----+               |     |-|--|  |
            +--+\ |    |                  |     | |  +--+
                 \| +-----+               |     | |
                  | |     |               |     | |  +--+
                  |\|     |               |     |-|--|CE|
                  | +-----+               +-----+ |  +--+
                  |        \              /       |
                  |          +---+    +---+       |
                  |          | P |....| P |       |
                  |          +---+    +---+       |
                  |                               |
                  +-------------------------------+
     
                   Figure 4: GVPXC Reference Model
        The bandwidth associated with each GVPXC depends on the access
        bandwidth of each CE to the GVPXC and the port topology
        implemented within the GVPXC. As sites are added or removed to
        the GVPXC, the total GVPXC bandwidth is accordingly adjusted.
     
        The basic unit of the GVPXC service is a GMPLS LSP between a
        port on one CE and a port on another CE crossing the GVPXC
        node. In the case of TDM LSP, rules are driven by [GMPLS-SONET-
        SDH] for SDH/Sonet interfaces. These rules must be used when
        establishing TDM connections from CE-port(s) to CE-port(s) over
        the GVPXC. The number of ports depends on the concatenation
        capabilities of these interfaces keeping in mind that when
        provided, virtual concatenation does not constraint the GVPXC
        port capability. If a port on CE has multiplexing capabilities,
        the same port could be used to connect to more than one
        (remote) CE ports.
     
        A GVPXC port can be moved to another PE port (or even to
        another PE) without changing the GVPXC addressing used by the
        customer to request connectivity. Addition/Deletion/Changes of
        the VPOXC port addresses requires no coordination with the
        service provider addressing scheme. GVPXC may be used by a
        customer to exchange customer’s GMPLS routing information
        related to the customer’s network, as from customer’s point of
        view (and specifically from customer’s routing/signaling point
        of view) the service appears as a single GMPLS-capable node.
     
     Ould-Brahim & Rekhter.      November 2004                   [Page 13]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
      3.1 GVPXC Routing Considerations
     
        From a customer’s point of view a GVPXC can be deployed in one
        of the two deployment scenarios:
     
        a) with off-line path computation or
        b) with on-line path computation
     
        In off-line path computation mode, an off-line tool is used by
        the customer to compute paths for all LSPs that cross the GVPXC
        node. Each node within the private network is provided with the
        outcome of computation for the LSP that cross the GVPXC and are
        originated by the node.
     
        On-line path computation assumes that the GVPXC node
        participates in the GMPLS routing with customer’s network , or
        to be more precise, participates in flooding GMPLS routing
        information of the client to whom that node belongs.
     
     
                                      GVPXC-A
                    +-----------------------------------------+
                    |       PE1                      PE2      |
                    |  +-----------+            +-----------+ |
        +-----+ VPN-LSP|           |            |           | | +-----+
        |CE1-A|<--------->+------+   GVSI-LSP   | +------+  | | |CE2-A|
        +-----+     |  |  |GVSI-A| |<---------->| |GVSI-A|<---->+-----+
                    |  |  +------+ |            | +------+  | |
                    +-----------------------------------------+
                       |           |            |           |
                       |           |  GVPXC-B   |           |
                    +-----------------------------------------+
        +-----+ VPN-LSP|  +------+ |            | +------+  | | +-----+
        |CE1-B|<--------->|GVSI-B| | GVSI-LSP   | |GVSI-B|<---->|CE2-B|
        +-----+     |  |  +------+ |<---------->| +------+  | | +-----+
                    |  |           |            |           | |
                    |  +-----------+            +-----------+ |
                    |                                         |
                    +-----------------------------------------+
     
                            Figure 5: Anatomy of the GVPXC
     
     
        In order for the GVPXC to participate in GMPLS routing with the
        customer’s network, the GVPXC needs to a) establish a routing
        adjacency with attached CEs, b) generate routing information
        with traffic engineering (TE) information for the set of CE-PE
        TE-links attached to the GVPXC, and c) floods TE-Link routing
        information (such as the ones learnt from other customer’s
        network  nodes) to the attached CEs using normal GMPLS routing
        procedures.
     
     
     Ould-Brahim & Rekhter.      November 2004                   [Page 14]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
        To accomplish the above steps, each PE maintains for each GVPXC
        service VPN information tables. We refer to such information as
        Generalized Virtual Switching Instance (GVSI). A GVSI can be
        viewed as a combination of GVPXC Routing and Forwarding tables
        and GVPXC Port information Table. GVSIs associated with one
        GVPXC are inter-connected by tunnel-based control channels. One
        realization of the control channel between a pair of GVSI is to
        use an IP/MPLS-based tunnels where plain private IGP adjacency
        can be established. Note that such adjacency is only used for
        distributing customer's routing information among the GVSIs.
     
        When receiving routing updates from the CE neighbors, the PE
        (or more precisely the GVSI configured on that PE) updates its
        IGP database and propagates the updates to other GVSIs using
        basic IGP procedures across the tunnel-based control-channels.
        The approach for distributing private reachability is similar
        to the virtual router approach used in layer-3 VPNs with the
        exception that a) the tunnel-based control channels are not
        visible to the CE and b) since the GVPXC represents a virtual
        node, the GVSIs will advertise VPN routing updates with the
        same GVPXC ROUTER_ID.
     
     3.2 Auto-Discovery
     
        VPN auto-discovery procedures described in [BGP-VPN-AUTO-
        DISCOVERY] are used to enable the PEs to determine which GVSIs
        are in the same GVPXC. Once the GVSIs are reachable through the
        control-based tunnels, private routes are then exchanged by
        running an instance of routing protocol per pair of GVSIs
        basis.
     
        Carrying GVSIs information in BGP-MP is done as follows. The
        NLRI address prefix is an address of one of the GVSIs
        configured on the PE.
     
        BGP Route target extended community is used to constrain route
        distribution between PEs (GVSIs). The BGP Next hop carries the
        service provider control-channel tunnel endpoint address which
        is in the service provider addressing space.
     
        In addition to GVSI related information, NLRI will also carry
        the tuples <CPIs, PPIs> as described in section 2.1.1.1. This
        information is used to establish end to end LSP between CEs
        across the GVPXC node (see section below).
     
     3.3 Signaling
     
        An LSP initiated within the VPN domain may contain a path that
        crosses the GVPXC node. We refer to the LSP that crosses the
        GVPXC node as a VPN-LSP. The creation/termination of a VPN-LSP
        could be driven either by mechanisms outside of GMPLS (e.g.,
        via configuration control on the CE), or by mechanisms within
        GMPLS (e.g., as a result of the CE at the head-end of the VPN-
        LSP receiving LSP setup requests originated by some other LSRs
        within the VPN space).
     Ould-Brahim & Rekhter.      November 2004                   [Page 15]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        A CE may decide to use the VPN-LSP as a forwarding Adjacency
        (FA) using procedures described in [LSP-HIERARCHY], and
        announces this LSP as a Traffic Engineering (TE) link into the
        same instance of the CE GMPLS control plane (or more precisely
        CE ISIS/OSPF component) as the one that was used to create the
        VPN-LSP. In this case, ISIS/OSPF floods the information about
        VPN-LSP just as it floods the information about any other
        links.  As a result of this flooding, an LSR within the VPN has
        in its TE link state database the information about not just
        basic TE links (from other nodes including GVPXC TE-links), but
        VPN-LSPs as well.
     
        In order to establish the VPN-LSPs, the GVSIs/PEs are inter-
        connected at the data-plane level through GMPLS-based LSPs. We
        refer to such LSPs as GVSI-LSPs (see figure 5). A GVSI-LSP is
        either pre-configured or constructed dynamically as a result of
        a PE receiving a VPN-LSP PATH message.  A given GVSI-LSP may
        map exactly to one VPN-LSP or to many VPN-LSPs. When a GVSI-LSP
        is created dynamically, its attributes are inherited from the
        VPN-LSP, which induced its creation and from the information
        maintained in the port information table associated with the
        GVSI. And for provisioned GVSI-LSPs, a policy-based mechanism
        may be needed to associate attributes to the GVSI-LSPs.
     
     
        Note that the bandwidth of the GVSI-LSP must be at least as big
        as the LSP that induced it, but may be bigger if only discrete
        bandwidths are available for the GVSI-LSP.
     
     
        Upon receiving the VPN-LSP PATH message, the ingress PE must
        then determine the egress PE using the GVSI IGP database and
        the PIT table or just the PIT table (in case the ERO contains
        already the destination CPI corresponding to an existing entry
        in the PIT table)The PE then tries to find an existing GVSI-LSP
        between the ingress PE and the egress PE .
     
        If a match is found, where the GVSI-LSP has enough unreserved
        bandwidth for the VPN-LSP being signaled, and the G-PID of the
        GVSI-LSP is compatible with the G-PID of the VPN-LSP being
        signaled, the PE uses that GVSI-LSP.
     
        Otherwise (if no existing GVSI-LSP is found), the PE sets up a
        new GVSI-LSP. That is, it initiates a new LSP setup just for
        the GVSI-LSP. Once the GVSI-LSP is established, the PE
        encapsulates the original VPN-LSP PATH message in an IP tunnel,
        and unicasts the message to the tail end of the GVSI-LSP.
     
        The Path message for the original VPN-LSP MUST contain an IF_ID
        RSVP_HOP object instead of an RSVP_HOP object; and the data
        interface identification MUST identify the GVSI-LSP. The
        ingress PE adjusts the ERO of the VPN-LSP path message and
        sends it to the egress PE of the GVSI-LSP, not to the next hop
        along the GVSI-LSP's path.
     Ould-Brahim & Rekhter.      November 2004                   [Page 16]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        The egress PE  will process the VPN-LSP using normal GMPLS
        signaling procedures and sends it to the egress CE. VPN-LSPs
        are then nested across the GVSI-LSPs.
     
     
     
     4. Others Issues
     
     
      o One vs more than one GVPN
     
        The solution described in this document requires each customer
        port to be in at most one GVPN, or to be more precise requires
        each customer port connected to a given PE to be associated
        with at most one PIT on that PE. It has been asserted that this
        requirement is too restrictive, as it doesn’t allow to realize
        certain connectivity scenarios. To understand why this
        assertion is incorrect we’d like to make several observations.
     
        First, the solution/mechanisms described in this document
        allows control connectivity between customers’ ports at the
        granularity of individual ports. This is because each local
        port on a PE could have its own PIT (GVSI), and the granularity
        of the information that is used to populate this PIT could be
        as fine as a single remote port (port on some other PE).
     
        Second, ports that are present in a given PIT need not have the
        same administrative control. For example, some ports in a given
        PIT may belong to the same organization (have the same
        administrative control) as the local ports associated with that
        PIT, while some other ports in exactly the same PIT may belong
        to organizations different from the one associated with the
        local ports. In that sense, a single PIT could combine both an
        Intranet and an Extranet.
     
        As a result, it should be abundantly obvious to the informed
        reader that the solution described in this document allows to
        realize any arbitrary inter-port connectivity matrix.
        Therefore, no other solution could be less restrictive than
        then one described in this document.
     
     
       o Exchanging VPN-ID between CE and PE
     
        The solution described in this document assumes that an
        association of a particular port on a CE with a particular GVPN
        (or to be more precise with a particular PIT on a PE) is done
        by the GVPN service provider, as part of the provisioning the
        port on the PE (associating the PE’s port with a particular
        PIT, and connecting the CE’s port with the PE’s port). Once
        this association is established, the CE could request
        establishment of an LSP to any customer’s port present in the
        PIT. Important to note that in order to select a particular
     Ould-Brahim & Rekhter.      November 2004                   [Page 17]


            draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        port within the PIT for the purpose of establishing an LSP to
        that port the only information that the CE needs to identify
        that port is the CPI of that port. Also important to note that
        the CPI is either an IP address, or a combination of
        <portindex, IP address>, but it doesn’t include any such thing
        as VPN-ID.
     
        Therefore, the solution described in this document doesn’t
        involve exchanging VPN-IDs between CE and PE in (GMPLS)
        signaling. Moreover, the lack of exchanging VPN-ID in signaling
        has no adverse effect on the ability to support any arbitrary
        inter-port connectivity matrix, and more generally on the
        flexibility of the solution described in this draft.
     
     
      o Multiple Routing Domains
     
        Since the protocol used to populate a PIT with remote
        information is BGP, since BGP works across multiple routing
        domains, and since GMPLS signaling isn’t restricted to a single
        routing domain, it follows that the mechanisms described in
        this document could support an environment that consists of
        multiple routing domains.
     
      o Addressing
     
        The mechanisms described in this document allow for a wide
        range of choices with respect to addresses used for CPI, PPI,
        and VPN-PPI. For example, one could use either IPv4 addresses,
        or IPv6 addresses, or NSAPs. Different GVPN customers of a
        given service provider may use different types of addresses.
        Moreover, different GVPNs attaching to the same PE  may use
        different addressing schemes. The types of addresses used for
        PPIs within a given service provider network are independent
        from the type of addresses used for CPI and VPN-PPI by the GVPN
        customers of that provider.
     
      o GVPNs and Layer-2/3  VPNs
     
        While in the context of this document a CE is a device that
        uses the GVPN service, such a device, in turn, could be used to
        offer VPN services (e.g., RFC2547, Virtual Routers, Layer 2
        VPNs) to other devices (thus becoming a PE with respect to
        these devices). Moreover, a CE device that uses the GVPN
        service could, in turn be used to offer GVPN services to other
        devices (thus becoming a PE with respect to these devices).
     
     5. Security Considerations
     
        Since association of a particular port with a particular GVPN
        (or to be more precise with a particular PIT) is done by the
        service provider as part of the service provisioning process
        (and thus can't be altered via signaling between CE and PE),
        and since signaling between CE and PE is assumed to be over a
     Ould-Brahim & Rekhter.      November 2004                   [Page 18]


             draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt        May 2004
     
        private network (and thus can't be spoofed by entities outside
        the private network), the solution described in this document
        doesn't require authentication in signaling.
     
     
     6. References
     
     
        [BGP-VPN-AUTODISCOVERY] Ould-Brahim, H.,  Rosen, E., Rekhter,
           Y., "Using BGP as an Auto-Discovery Mechanism for Network-
           based VPNs",  work in progress
     
        [GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS -
           Signaling Functional Description", January 2003, RFC3471.
     
        [GMPLS-RSVP-TE] Berger, L. (editor), "Generalized MPLS
           Signaling - RSVP-TE Extensions", RFC3473, January 2003.
     
        [GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions
           in Support of Generalized MPLS", work in progress
     
        [GMPLS-HIERARCHY] Kompella, K., Rekhter, Y., "LSP Hierarchy
           with Generalized MPLS TE", work in progress.
     
        [LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link
           Bundling in MPLS Traffic Engineering", work in progress.
     
        [GVPN-REQ] Ould-Brahim, H., Rekhter, Y., et al., "Service
           Requirements for Optical Virtual Private Networks", work in
           progress, July 2001.
     
        [GMPLS-OVERLAY] Swallow, G., et al., "GMPLS RSVP Support for
          the Overlay Model", work in progress.
     
     
     
     7. Author's Addresses
     
     
        Hamid Ould-Brahim
        Nortel Networks
        P O Box 3511 Station C
        Ottawa ON K1Y 4H7 Canada
        Phone: +1 (613) 765 3418
        Email: hbrahim@nortelnetworks.com
     
        Yakov Rekhter
        Juniper Networks
        1194 N. Mathilda Avenue
        Sunnyvale, CA 94089
        Email: yakov@juniper.net
     
     
     Ould-Brahim & Rekhter.      November 2004                   [Page 19]


         draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt       May 2004
     
        Don Fedyk
        Nortel Networks
        600 Technology Park
        Billerica, Massachusetts
        01821 U.S.A
        Phone: +1 (978) 288 3041
        Email: dwfedyk2nortelnetworks.com
     
        Peter Ashwood-Smith
        Nortel Networks
        P.O. Box 3511 Station C,
        Ottawa, ON K1Y 4H7, Canada
        Phone: +1 613 763 4534
        Email: petera@nortelnetworks.com
     
     
        Eric C. Rosen
        Cisco Systems, Inc.
        250 Apollo drive
        Chelmsford, MA, 01824
        E-mail: erosen@cisco.com
     
        Eric Mannie
        KPNQwest
        Terhulpsesteenweg 6A
        1560 Hoeilaart
        Belgium
        Phone: +32 2 658 56 52
        Email: eric.mannie@ebone.com
     
        Luyuan Fang
        AT&T
        200 Laurel Avenue
        Middletown, NJ 07748
        Email: Luyuanfang@att.com
        Phone: +1 (732) 420 1920
     
        John Drake
        Calient Networks
        5853 Rue Ferrari
        San Jose, CA 95138
        USA
        Phone: +1 408 972 3720
        Email: jdrake@calient.net
     
        Yong Xue
        UUNET/WorldCom
        Ashburn, Virginia
        (703)-886-5358
        yxue@uu.net
     
        Riad Hartani
        Caspian Networks
     Ould-Brahim & Rekhter.      November 2004                   [Page 20]


         draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt       May 2004
     
        170 Baytech Drive
        San Jose, CA 95143
        Phone: 408 382 5216
        Email: riad@caspiannetworks.com
     
        Dimitri Papadimitrio
        Alcatel
        Francis Wellesplein 1,
        B-2018 Antwerpen, Belgium
        Phone: +32 3 240-8491
        Email: Dimitri.Papadimitriou@alcatel.be
     
     
        Lou Berger
        Movaz Networks, Inc.
        7626 jones Branch Drive, Suite 615
        McLean, VA 22102
        Phone: +1 703 847 1801
        Email: lberger@movaz.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Ould-Brahim & Rekhter.      November 2004                   [Page 21]


         draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt       May 2004
     
     
     Full Copyright Statement
     
        Copyright (C) The Internet Society (2000). All Rights Reserved.
        This document and translations of it may be copied and
        furnished to others, and derivative works that comment on or
        otherwise explain it or assist in its implementation may be
        prepared, copied, published and distributed, in whole or in
        part, without restriction of any kind, provided that the above
        copyright notice and this paragraph are included on all such
        copies and derivative works. However, this document itself may
        not be modified in any way, such as by removing the copyright
        notice or references to the Internet Society or other Internet
        organizations, except as needed for the purpose of developing
        Internet standards in which case the procedures for copyrights
        defined in the Internet Standards process must be followed, or
        as required to translate it into languages other than English.
     
        The limited permissions granted above are perpetual and will
        not be revoked by the Internet Society or its successors or
        assigns.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Ould-Brahim & Rekhter.      November 2004                   [Page 22]
     

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/