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

Versions: (draft-kumaki-l3vpn-e2e-rsvp-te-reqts) 00 01 02 03 04 05 RFC 5824

    Network Working Group
    Internet Draft                                        K. Kumaki, Ed.
    Intended Status: Informational                      KDDI Corporation
    Created: December 28, 2009                                  R. Zhang
    Expires: June 27, 2010                                            BT
                                                               Y. Kamite
                                                      NTT Communications
 
 
 
        Requirements for supporting Customer RSVP and RSVP-TE over a
                              BGP/MPLS IP-VPN
 
                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05.txt
 
 
 Status of this Memo
 
    This Internet-Draft is submitted to IETF in full conformance with
    the provisions of BCP 78 and BCP 79.
 
    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.
 
    This Internet-Draft will expire on June 27, 2010.
 
 Copyright Notice
 
    Copyright (c) 2009 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents in effect on the date of
    publication of this document (http://trustee.ietf.org/license-info).
    Please review these documents carefully, as they describe your
    rights
 
 K.Kumaki, et al.                                              [Page 1]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    and restrictions with respect to this document.
 
    This document may contain material from IETF Documents or IETF
    Contributions published or made publicly available before November
    10, 2008.  The person(s) controlling the copyright in some of this
    material may not have granted the IETF Trust the right to allow
    modifications of such material outside the IETF Standards Process.
    Without obtaining an adequate license from the person(s)
    controlling the copyright in such materials, this document may not
    be modified outside the IETF Standards Process, and derivative
    works of it may not be created outside the IETF Standards Process,
    except to format it for publication as an RFC or to translate it
    into languages other than English.
 
 Abstract
 
    Today, customers expect to run triple play services through
    BGP/MPLS IP-VPNs. Some Service Providers will deploy services that
    request QoS guarantees from a local CE to a remote CE across the
    network. As a result, the application (e.g., voice, video,
    bandwidth-guaranteed data pipe, etc.) requirements for an end-to-
    end QOS and reserving an adequate bandwidth continue to increase.
 
    Service Providers can use both an MPLS and an MPLS-TE LSP to meet
    the service objectives. This document describes service provider
    requirements for supporting a customer RSVP and RSVP-TE over a
    BGP/MPLS IP-VPN.
 
 Requirements Language
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
    this document are to be interpreted as described in [RFC2119].
 
 Table of Contents
 
    1. Introduction..................................................3
    2. Terminology...................................................4
    3. Problem Statement.............................................5
    4. Application Scenarios.........................................7
       4.1 Scenario I: Fast Recovery over BGP/MPLS IP-VPNs...........7
       4.2 Scenario II: Strict C-TE LSP QoS Guarantees...............8
       4.3 Scenario III: Load Balance of CE-to-CE Traffic............9
       4.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels.......10
       4.5 Scenario V: RSVP over Non-TE LSPs........................11
       4.6 Scenario VI: RSVP-TE over Non-TE LSPs....................12
    5. Detailed Requirements for C-TE LSPs Model....................12
       5.1  Selective P-TE LSPs.....................................12
       5.2  Graceful Restart Support for C-TE LSPs..................13
 
 
 
 K.Kumaki, et al.                                              [Page 2]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
       5.3  Rerouting Support for C-TE LSPs.........................13
       5.4  FRR Support for C-TE LSPs...............................13
       5.5  Admission Control Support on P-TE LSP Head-Ends.........13
       5.6  Admission Control Support for C-TE LSPs in LDP-based Core
       Networks.....................................................14
       5.7  Policy Control Support for C-TE LSPs....................14
       5.8  PCE Features Support for C-TE LSPs......................14
       5.9  Diversely Routed C-TE LSPs Support......................15
       5.10 Optimal Path Support for C-TE LSPs......................15
       5.11 Reoptimization Support for C-TE LSPs....................15
       5.12 DS-TE Support for C-TE LSPs.............................15
    6. Detailed Requirements for C-RSVP Paths Model.................16
       6.1  Admission Control between PE-CE for C-RSVP Paths........16
       6.2  Aggregation of C-RSVP Paths by P-TE LSPs................16
       6.3  Non-TE LSPs support for C-RSVP Paths....................16
       6.4  Transparency of C-RSVP Paths............................16
    7. Common Detailed Requirements for Two Models..................16
       7.1  CE-PE Routing...........................................17
       7.2  Complexity and Risks....................................17
       7.3  Backward Compatibility..................................17
       7.4  Scalability Considerations..............................17
       7.5  Performance Considerations..............................17
       7.6  Management Considerations...............................18
    8. Security Considerations......................................18
    9. IANA Considerations..........................................19
    10. References..................................................19
       10.1 Normative References....................................19
       10.2 Informative References..................................20
    11. Acknowledgments.............................................21
    12. Author's Addresses..........................................21
    Appendix A. Reference Model.....................................21
       A.1 End-to-End C-RSVP Path Model.............................22
       A.2 End-to-End C-TE LSP Model................................22
 
 1. Introduction
 
    Some Service Providers want to build a service which guarantees
    QoS and a bandwidth from a local CE to a remote CE through the
    network. A CE includes the network client equipment owned and
    operated by the service provider. However, the CE may not be part
    of the MPLS provider network.
 
    Today, customers expect to run triple play services such as the
    internet access, the telephone and the television through BGP/MPLS
    IP-VPNs [RFC4364].
    As these services evolve, the requirements for an end-to-end QoS
    to meet the application requirements also continue to grow.
    Depending on the application (e.g., voice, video, bandwidth-
    guaranteed data pipe, etc.), a native IP using an RSVP and/or an
 
 
 
 K.Kumaki, et al.                                              [Page 3]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    end-to-end constrained MPLS-TE Label Switched Path (LSP) may be
    required. The RSVP path may be used to provide QoS guarantees and
    reserve an adequate bandwidth for the data. An end-to-end MPLS-TE
    LSP may also be used to guarantee a bandwidth, and provide
    extended functionality like MPLS fast reroute (FRR)[RFC4090] for
    maintaining the service continuity around node and link,
    including the CE-PE link, failures. It should be noted that an
    RSVP session between two CEs may also be mapped and tunneled into
    an MPLS-TE LSP across an MPLS provider network.
 
    A number of advantages exist for deploying the model previously
    mentioned. The first is that customers can use these network
    services whilst being able to use both private addresses and
    global addresses. The second advantage is that the traffic is
    tunneled through the Service Provider backbone, so that the
    customer traffic and the route confidentiality are maintained.
 
    This document defines a reference model, example application
    scenarios and detailed requirements for a solution supporting
    a customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN.
 
    Specification for a solution is out of scope in this document.
 
 2. Terminology
 
    This document uses the BGP/MPLS IP-VPN terminology defined in
    [RFC4364]. The document also uses Path Computation Element terms
    which are defined in [RFC4655].
 
    TE LSP: Traffic Engineering Label Switched Path
 
    MPLS TE LSP: Multi Protocol Label Switching TE LSP
 
    C-RSVP path: Customer RSVP path: a native RSVP path with the
    bandwidth reservation of X for customers
 
    C-TE LSP: Customer Traffic Engineering Label Switched Path:
              an end-to-end MPLS TE LSP for customers
 
    P-TE LSP: Provider Traffic Engineering Label Switched Path: a
              transport TE LSP between two PEs
 
    Head-end LSR: an ingress LSR
 
    Tail-end LSR: an egress LSR
 
    LSR: a Label Switched Router
 
 
 
 
 
 K.Kumaki, et al.                                              [Page 4]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
 3. Problem Statement
 
    Service Providers want to deliver triple play services with QOS
    guarantees to their customers. Various techniques are available to
    achieve this. Some Service Providers will wish to offer advanced
    services using an RSVP signaling for native IP flows (C-RSVP) or
    an RSVP-TE signaling for Customer TE LSPs (C-TE LSPs) over
    BGP/MPLS IP-VPNs.
 
    The following examples outline each method:
 
    A C-RSVP path with the bandwidth reservation of X can be used to
    transport the voice. In order to achieve the sub-50msec recovery
    during link, node and SRLG failures and to provide strict QoS
    guarantees, a C-TE LSP with the bandwidth X between data centers
    or customer sites can be used to carry the voice and the video
    traffic. Thus, service providers or customers can choose a C-RSVP
    path or a C-TE LSP to meet their requirements.
 
    When service providers offer a C-RSVP path between hosts or CEs
    over BGP/MPLS IP-VPNs, the CE/host requests an end-to-end C-RSVP
    path with the bandwidth reservation of X to the remote CE/host.
    However, if a C-RSVP signaling is to send within a VPN, the
    service provider network will face scalability issues because
    routers need to retain the RSVP state per a customer. Therefore,
    in order to solve scalability issues, multiple C-RSVP
    reservations can be aggregated at a PE, where a P-TE LSP
    head-end can perform the admission control using the aggregated
    C-RSVP reservations. The method that is described in RFC4804 can
    be considered as a useful approach. In this case, a reservation
    request from within the context of a VRF can get aggregated onto
    a P-TE LSP. The P-TE LSP can be pre-established, resized based on
    the request, or triggered by the request. Service providers,
    however, cannot provide a C-RSVP path over the VRF instance as
    defined in RFC4364. The current BGP/MPLS IP-VPN architecture also
    does not support an RSVP instance running in the context of a VRF
    to process RSVP messages and integrated services (int-serv)
    [RFC1633][RFC2210]. One of solutions is described in [RSVP-L3VPN].
 
    If service providers offer a C-TE LSP from a CE to a CE over the
    BGP/MPLS IP-VPN, they require that a MPLS TE LSP from a local CE
    to a remote CE be established. However, if a C-TE LSP signaling
    is to send within the VPN, the service provider network may face
    the following scalability issues:
 
    - A C-TE LSP can be aggregated by a P-TE LSP at a PE. (i.e.
      hierarchical LSPs) In this case, only a PE maintains the state
      about customer RSVP sessions.
 
 
 
 
 K.Kumaki, et al.                                              [Page 5]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    - A C-TE LSP cannot be aggregated by a P-TE LSP at a PE depending
      on some policies. (i.e. continuous LSPs)
      In this case, both Ps and PEs maintain the state about customer
      RSVP sessions.
 
    - A C-TE LSP can be aggregated by the non-TE LSP (i.e. LDP).
      In this case, only a PE maintains the state about customer
      RSVP-TE sessions.
      Note that it is assumed there is always enough bandwidth
      available in the service provider core network.
 
    Furthermore, if service providers provide the C-TE LSP over the
    BGP/MPLS IP-VPN, they currently cannot provide it over the VRF
    Instance as defined in RFC4364. Specifically the current BGP/MPLS
    IP-VPN architecture does not support the RSVP-TE instance running
    in the context of a VRF to process RSVP messages and trigger the
    establishment of the C-TE LSP over the service provider core
    network. If every C-TE LSP is to trigger the establishment or
    resizing of a P-TE LSP, the service provider network will also
    face scalability issues that arise from maintaining a large number
    of the P-TE LSP and/or the dynamic signaling of these P-TE LSPs.
    Section 8.4, Scalability Considerations, of this document provides
    the detailed scalability requirements.
 
    Two different models are described above. The differences between
    C-RSVP paths and C-TE LSPs are as follows:
 
    - C-RSVP path model: data packets among CEs are forwarded by
    "native IP packets" (i.e. not labeled packets).
 
    - C-TE LSP model: data packets among CEs are forwarded by
    "labeled IP packets".
 
    Depending on the service level and the need to meet specific
    requirements, service providers should be able to choose P-TE LSPs
    or non-TE LSPs in the backbone network. The selection may be
    dependent on the Service Providers policy and the node capability
    to support the mechanisms described.
 
    The following items are required selectively to support C-RSVP
    paths and C-TE LSPs over BGP/MPLS IP-VPNs based on the service
    level. For example, some service providers need all of the
    following items to provide a service. Some service providers need
    some of them to provide the service. It depends on a service level
    and a policy of service providers. Detailed requirements are
    described in sections 6, 7 and 8.
 
    - C-RSVP path QoS guarantees.
    - Fast recovery over the BGP/MPLS IP-VPN to protect traffic for
 
 
 
 K.Kumaki, et al.                                              [Page 6]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    the C-TE LSP against the CE-PE link failure and the PE node
    failure.
    - Strict C-TE LSP bandwidth and QoS guarantees.
    - Resource optimization for C-RSVP paths and C-TE LSPs.
    - Scalability for C-RSVP paths and C-TE LSPs.
 
 4. Application Scenarios
 
    The following sections present a few application scenarios for
    C-RSVP paths and C-TE LSPs in BGP/MPLS IP-VPN environments.
    Appendix A. (Reference Model), describes a C-RSVP path, a C-TE LSP
    and a P-TE LSP.
 
    In all scenarios, it is the responsibility of the service provider
    to ensure that the enough bandwidth is available to meet the
    customers application requirements.
 
 4.1 Scenario I: Fast Recovery over BGP/MPLS IP-VPNs
 
    In this scenario, as shown in figure 1, a customer uses a VoIP
    application between its sites (i.e., between CE1 and CE2).
    H0 and H1 are voice equipments.
 
    In this case, the customer establishes C-TE LSP1 as a primary
    Path and C-TE LSP2 as a backup path. If the link between PE1
    and CE1 or the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a
    path protection.
 
    Generally speaking, C-RSVP paths are used by customers and P-TE
    LSPs are used by service providers.
 
                                 C-TE LSP1
              <---------------------------------------------->
                                 P-TE LSP1
                       <--------------------------->
    .............                                         .............
    . ---   --- .     ---      ---       ---      ---     . ---   --- .
    .|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |.
    . ---   --- .     ---      ---       ---      ---     . ---   --- .
    .........|...     ---      ---       ---      ---     ...|.........
             +-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
                      ---      ---       ---      ---
 
                       <--------------------------->
                                 P-TE LSP2
              <---------------------------------------------->
                                 C-TE LSP2
 
    <--customer-->    <--------BGP/MPLS IP-VPN------->    <--customer->
 
 
 
 K.Kumaki, et al.                                              [Page 7]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
       network                                               network
 
                            Figure 1 Scenario I
 
 4.2 Scenario II: Strict C-TE LSP QoS Guarantees
 
    In this scenario, as shown in figure 2, a service provider B
    transports the voice and the video traffic between its sites (i.e.,
    between CE1 and CE2).
    In this case, the service provider B establishes C-TE LSP1 with
    the preemption priority 0 and the bandwidth 100Mbps for the voice
    traffic, and C-TE LSP2 with the preemption priority 1 and the
    bandwidth 200Mbps for the unicast video traffic. On the other hand,
    a service provider A also pre-establishes P-TE LSP1 with the
    preemption priority 0 and the bandwidth 1Gbps for the voice
    traffic, and P-TE LSP2 with the preemption priority 1 and the
    bandwidth 2Gbps for the video traffic. These P-TE LSP1 and P-TE
    LSP2 should support DS-TE. [RFC4124]
 
    PE1 and PE3 should choose an appropriate P-TE LSP based on the
    preemption priority. In this case, C-TE LSP1 must be associated
    with P-TE LSP1 at PE1 and C-TE LSP2 must be associated with P-TE
    LSP2 at PE3.
 
    Furthermore, PE1 and PE3 head-ends should control the bandwidth of
    C-TE LSPs. In this case, PE1 and PE3 can choose C-TE LSPs by the
    amount of max available bandwidth for each P-TE LSP, respectively.
 
                                 C-TE LSP1
              <---------------------------------------------->
                                 P-TE LSP1
                       <--------------------------->
    .............                                         .............
    . ---   --- .     ---      ---       ---      ---     . ---   --- .
    .|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|.
    . ---   --- .     ---      ---       ---      ---     . ---   --- .
    .........|...     ---      ---       ---      ---     ...|.........
             +-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
                      ---      ---       ---      ---
 
                       <--------------------------->
                                 P-TE LSP2
              <---------------------------------------------->
                                 C-TE LSP2
 
     <---SP B---->    <--------BGP/MPLS IP-VPN------->     <---SP B--->
        network                 SP A network                 network
 
                            Figure 2 Scenario II
 
 
 
 K.Kumaki, et al.                                              [Page 8]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
 
    It's possible that the customer and the service provider have
    differing preemption priorities. In this case, the PE policy will
    override the customers. In the case that the service provider does
    not support preemption priorities then priorities should be
    ignored.
 
 4.3 Scenario III: Load Balance of CE-to-CE Traffic
 
    In this scenario, as shown in figure 3, the service provider C
    uses the voice and the video traffic between its sites (i.e.,
    between CE0 and CE5/CE7, between CE2 and CE5/CE7, between CE5 and
    CE0/CE2, and between CE7 and CE0/CE2). H0 and H1 are voice and
    video equipments. In this case, the service provider C establishes
    C-TE LSP1, C-TE LSP3, C-TE LSP5 and C-TE LSP7 with the preemption
    priority 0 and the bandwidth 100Mbps for the voice traffic, and
    establishes C-TE LSP2, C-TE LSP4, C-TE LSP6 and C-TE LSP8 with the
    preemption priority 1 and the bandwidth 200Mbps for the video
    traffic. On the other hand, the service provider A also pre-
    establishes P-TE LSP1 and P-TE LSP3 with the preemption priority 0
    and the bandwidth 1Gbps for the voice traffic, and P-TE LSP2 and
    P-TE LSP4 with the preemption priority 1 and the bandwidth 2Gbps
    for the video traffic. These P-TE LSP1, P-TE LSP2, P-TE LSP3 and
    P-TE LSP4 should support DS-TE.[RFC4124]
 
    All PEs should choose an appropriate P-TE LSP based on the
    preemption priority. To minimize the traffic disruption due to a
    single network failure, diversely routed C-TE LSPs are
    established. In this case, the FRR [RFC4090] is not necessarily
    required.
 
    Also, unconstrained TE LSPs (i.e., C-TE LSPs/P-TE LSPs with the 0
    bandwidth) [RFC5330] are applicable to this scenario.
 
    Furthermore, the load balancing for a communication between H0
    and H1 can be done by setting up full mesh C-TE LSPs between
    CE0/CE2 and CE5/CE7.
 
              C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5)
                                    (CE0<-CE1<-...<-CE4<-CE5)
             <---------------------------------------------->
 
 
              C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7)
                                    (CE2<-CE1<-...<-CE4<-CE7)
             <---------------------------------------------->
                              P-TE LSP1 (p=0)
                          <-------------------->
                              P-TE LSP2 (p=1)
 
 
 
 K.Kumaki, et al.                                              [Page 9]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
                          <-------------------->
    ..................                             ..................
    .      ---   --- .  ---    ---     ---    ---  . ---   ---      .
    .     |CE0|-|CE1|--|PE1|--|P1 |---|P2 |--|PE2|--|CE4|-|CE5|     .
    . --- /---   --- .  ---     ---    ---    ---  . ---   ---\ --- .
    .|H0 |     +     .              +              .     +     |H1 |.
    . --- \---   --- .  ---    ---     ---    ---  . ---   ---/ --- .
    .     |CE2|-|CE3|--|PE3|--|P3 |---|P4 |--|PE4|--|CE6|-|CE7|     .
    .      ---   --- .  ---    ---     ---    ---  . ---   ---      .
    ..................                             ..................
                          <-------------------->
                              P-TE LSP3 (p=0)
                          <-------------------->
                              P-TE LSP4 (p=1)
             <---------------------------------------------->
              C-TE LSP5(P=0),6(P=1)  (CE0->CE3->...->CE6->CE5)
                                     (CE0<-CE3<-...<-CE6<-CE5)
 
             <---------------------------------------------->
              C-TE LSP7(P=0),8(P=1)  (CE2->CE3->...->CE6->CE7)
                                     (CE2<-CE3<-...<-CE6<-CE7)
 
     <-----SP C----->   <----BGP/MPLS IP-VPN---->   <-----SP C----->
          network               SP A network             network
 
                           Figure 3 Scenario III
 
 4.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels
 
     In this scenario, as shown in figure 4, the customer has two hosts
     connecting off CE1 and CE2 respectively. CE1 and CE2 are connected
     to PE1 and PE2, respectively, within a VRF instance belonging to
     the same VPN. The requesting host (H1) may request to the H2 an
     RSVP path with the bandwidth reservation of X. This reservation
     request from within the context of VRF will get aggregated onto a
     pre-established P-TE/DS-TE LSP based upon procedures similar to
     [RFC4804]. As in the case of [RFC4804], there may be multiple P-TE
     LSPs belonging to different DS-TE class-types. Local policies can
     be implemented to map the incoming RSVP path request from H1 to
     the P-TE LSP with the appropriate class-type. Please note that the
     e2e RSVP path request may also be initiated by the CE devices
     themselves.
 
                                  C-RSVP path
          <----------------------------------------------------->
 
                                  P-TE LSP
                       <--------------------------->
      .............                                     .............
 
 
 
 K.Kumaki, et al.                                             [Page 10]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .............                                     .............
                     ^                               ^
                     |                               |
                 vrf instance                    vrf instance
 
       <-customer->   <--------BGP/MPLS IP-VPN------->   <-customer->
         network                                           network
 
                             Figure 4 Scenario IV
 
 4.5 Scenario V: RSVP over Non-TE LSPs
 
    In this scenario, as shown in figure 5, a customer has two hosts
    connecting off CE1 and CE2, respectively. CE1 and CE2 are
    connected to PE1 and PE2, respectively, within a VRF instance
    belonging to the same VPN. The requesting host (H1) may request
    to H2 an RSVP path with the bandwidth reservation of X. In this
    case, a non-TE LSP (i.e. LDP etc) is provided between PEs and has
    LDP which supports MPLS diffserv [RFC3270].
    Note that this only provides Diffserv and not the bandwidth
    reservation as is done with RSVP-TE.
 
    Local policies can be implemented to map the customer's reserved
    flow to the LSP with the appropriate Traffic Class [RFC5462] at
    PE1.
 
                                 C-RSVP path
                <------------------------------------------>
 
                                 Non-TE LSP
                       <--------------------------->
      .............                                     .............
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .............                                     .............
                     ^                               ^
                     |                               |
                 vrf instance                    vrf instance
 
       <-customer->   <-------BGP/MPLS IP-VPN------->   <-customer->
         network                                          network
 
                             Figure 5 Scenario V
 
 
 
 
 
 K.Kumaki, et al.                                             [Page 11]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
 4.6 Scenario VI: RSVP-TE over Non-TE LSPs
 
    In this scenario, as shown in figure 6, a customer uses a VoIP
    application between its sites (i.e., between CE1 and CE2). H0
    and H1 are voice equipments. In this case, a non-TE LSP means
    LDP and the customer establishes C-TE LSP1 as a primary path and
    C-TE LSP2 as a backup path. If the link between PE1 and CE1 or
     the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path
     protection.
 
                                C-TE LSP1
                <----------------------------------------->
                                Non-TE LSP
                       <-------------------------->
      .............                                     .............
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .|H0 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H1 |.
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .........|...   ---      ---       ---      ---   ...|.........
               +-----|PE3|----|P3 |-----|P4 |----|PE4|-----+
                      ---      ---       ---      ---
 
                       <-------------------------->
                                Non-TE LSP
                <----------------------------------------->
                                C-TE LSP2
 
      <-customer->     <------BGP/MPLS IP-VPN------>    <-customer->
         network                                           network
 
                          Figure 6 Scenario VI
 
 5. Detailed Requirements for C-TE LSPs Model
 
    This section describes detailed requirements for C-TE LSPs in
    BGP/MPLS IP-VPN environments.
 
 5.1  Selective P-TE LSPs
 
    The solution MUST provide the ability to decide which P-TE LSPs a
    PE uses for a C-RSVP path and a C-TE LSP. When a PE receives a
    native RSVP and/or a path messages from a CE, it MUST be able to
    decide which P-TE LSPs it uses. In this case, various kinds of
    P-TE LSPs exist in the service provider network. For example, the
    PE MUST choose an appropriate P-TE LSP based on local policies
    such as:
 
    1. preemption priority
    2. affinity
 
 
 
 K.Kumaki, et al.                                             [Page 12]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    3. class-type
    4. on the data plane: (DSCP or Traffic Class bits)
 
 5.2  Graceful Restart Support for C-TE LSPs
 
    The solution SHOULD support the graceful restart capability,
    where the C-TE LSP traffic continues to be forwarded during a PE
    graceful restart, graceful restart mechanisms related to this
    architecture are described in [RFC3473], [RFC3623] and [RFC4781].
 
 5.3  Rerouting Support for C-TE LSPs
 
    The solution MUST provide the rerouting of a C-TE LSP in case of
    Link, node and SRLG failures or preemption. Such rerouting may be
    controlled by a CE or by a PE depending on the failure. In a dual
    homed environment, the ability to perform the rerouting MUST be
    provided against a CE-PE link failure or a PE failure if another
    is available between the head-end and the tail-end of the C-TE
    LSP.
 
 5.4  FRR Support for C-TE LSPs
 
    The solution MUST support FRR [RFC4090] features for a C-TE LSP
    over a vrf instance.
    In BGP/MPLS IP-VPN environments, a C-TE LSP from a CE traverses
    multiple PEs and Ps, albeit tunneled over a P-TE LSP. In order to
    avoid PE-CE link/PE node/SRLG failures, a CE (a customer's head-end
    router) needs to support the link protection or the node
    protection.
 
    The following protection MUST be supported:
 
    1. CE link protection
    2. PE node protection
    3. CE node protection
 
 5.5  Admission Control Support on P-TE LSP Head-Ends
 
    The solution MUST support the admission control on a P-TE LSP
    tunnel head-end for C-TE LSPs. C-TE LSPs may potentially try to
    reserve the bandwidth that exceeds the bandwidth of the P-TE LSP.
    The P-TE LSP tunnel head-end SHOULD control the number of
    C-TE LSPs and/or the bandwidth of C-TE LSPs. For example, the
    transport TE LSP head-end SHOULD have a configurable limit on
    the maximum number of C-TE LSPs that it can admit from a CE. As
    for the amount of bandwidth that can be reserved by C-TE LSPs
    there could be two situations:
 
    1. Let the P-TE LSP do its natural bandwidth admission
 
 
 
 K.Kumaki, et al.                                             [Page 13]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    2. Set a cap on the amount of bandwidth and have the configuration
    option to:
 
        a. Reserve the minimum of the cap bandwidth or the C-TE LSP
       bandwidth on the P-TE LSP if the required bandwidth is available
        b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP
       is not available
 
 5.6  Admission Control Support for C-TE LSPs in LDP-based Core
      Networks
 
    The solution MUST support the admission control for a C-TE LSP at
    a PE in the LDP-based core network. Specifically, PEs MUST have a
    configurable limit on the maximum amount of bandwidth that can be
    reserved by C-TE LSPs per a vrf instance (i.e. per a customer).
    Also, a PE SHOULD have a configurable limit on the total amount of
    bandwidth that can be reserved by C-TE LSPs between PEs.
 
 5.7  Policy Control Support for C-TE LSPs
 
    The solution MUST support the policy control for a C-TE LSP at a
    PE.
 
    The PE MUST be able to perform the following:
 
    1. Limit the rate of RSVP messages per CE link.
    2. Accept and map or reject requests for a given affinity.
    3. Accept and map or reject requests with a specified setup and/or
    pre-emption priorities.
    4. Accept or reject requests for fast reroutes.
    5. Neglect the requested setup and/or pre-emption priorities and
    select a P-TE LSP based on a local policy that applies to the CE-PE
    link or the VRF.
    6. Ignore the requested affinity and select a P-TE LSP based on a
    local policy that applies to the CE-PE link or the VRF.
    7. Perform mapping in data plane between customer traffic class
    bits and transport P-TE LSP traffic class bits, as signaled per
    [RFC3270].
 
 5.8  PCE Features Support for C-TE LSPs
 
    The solution SHOULD support the PCE architecture for a C-TE LSP
    establishment in the context of a VRF instance. When a C-TE LSP is
    provided, CEs, PEs and Ps may support PCE [RFC4655] and [RFC5440]
    features.
 
    In this case, CE routers or PE routers may be PCCs and PE routers
    and/or P routers may be PCEs. Furthermore, the solution SHOULD
    support a mechanism for the dynamic PCE discovery. Specifically,
 
 
 
 K.Kumaki, et al.                                             [Page 14]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    all PCEs are not necessarily discovered automatically and only
    specific PCEs that know VPN routes should be discovered
    automatically.
 
 5.9  Diversely Routed C-TE LSPs Support
 
    The solution MUST provide for setting up diversely routed C-TE
    LSPs over the VRF instance. These diverse C-TE LSPs MAY be
    traversing over two different P-TE LSPs that are fully disjoint
    within a service provider network. When a single CE has multiple
    uplinks which connect to different PEs, it is desirable that
    multiple C-TE LSPs over the VRF instance are established between
    a pair of LSRs. When two CEs have multiple uplinks which connect
    to different PEs, it is desirable that multiple C-TE LSPs over the
    VRF instance are established between two different pairs of LSRs.
    In these cases, for example, the following points will be
    beneficial to customers.
 
    1. load balance of the CE-to-CE traffic across diverse C-TE LSPs
    so as to minimize the traffic disruption in case of a single
    network element failure
    2. path protection (e.g. 1:1, 1:N)
 
 5.10  Optimal Path Support for C-TE LSPs
 
    The solution MUST support the optimal path for a C-TE LSP over the
    VRF instance. Depending on an application (e.g. voice and video),
    an optimal path is needed for a C-TE LSP over the vrf instance. An
    optimal path may be a shortest path based on the TE metric, in the
    case of a TE-LSP or an IGP metric, in the case of LDP.
 
 5.11  Reoptimization Support for C-TE LSPs
 
    The solution MUST support the reoptimization of a C-TE LSP over
    the VRF instance. These LSPs MUST be reoptimized using
    make-before-break[RFC3209].
    In this case, it is desirable for a CE to be configured with
    regard to the timer-based or event-driven reoptimization.
    Furthermore, customers SHOULD be able to reoptimize a C-TE LSP
    manually. To provide the delay-sensitive or jitter-sensitive
    traffic (i.e. the voice traffic), a C-TE LSP path computation
    and a route selection are expected to optimal for the specific
    application.
 
 5.12  DS-TE Support for C-TE LSPs
 
    The solution MUST support DS-TE [RFC4124] for a C-TE LSP over the
    VRF instance. In the event that the service provider and the
    customer have differing bandwidth constraint models, then only
 
 
 
 K.Kumaki, et al.                                             [Page 15]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    the service provider bandwidth model should be supported.
 
    Applications, which have different traffic characteristics, are
    used
    in BGP/MPLS IP-VPN environments. Service providers try to achieve
    the fine-grained optimization of transmission resources,
    efficiency and further enhanced network performance. It may be
    desirable to perform TE at a per-class level.
 
    By mapping the traffic from a given diff-serv class of service on
    a separate C-TE LSP, it allows this traffic to utilize resources
    available to the given class on both shortest paths and
    non-shortest paths, and follow paths that meet TE constraints
    which are specific to the given class.
 
 6. Detailed Requirements for C-RSVP Paths Model
 
    This section describes detailed requirements for C-RSVP paths in
    BGP/MPLS IP-VPN environments.
 
 6.1  Admission Control between PE-CE for C-RSVP Paths
 
    The solution MUST support the admission control at the ingress PE.
    PEs MUST control RSVP messages per a vrf.
 
 6.2  Aggregation of C-RSVP Paths by P-TE LSPs
 
    The solution SHOULD support C-RSVP paths aggregated by P-TE LSPs.
    P-TE LSPs SHOULD be pre-established manually or dynamically by
    operators, and MAY be established triggered by C-RSVP messages.
    Also, the P-TE LSP SHOULD support DS-TE.
 
 6.3  Non-TE LSPs support for C-RSVP Paths
 
    The solution SHOULD support non-TE LSPs (i.e. LDP-based LSP,
    etc). They are established by LDP [RFC5036] between PEs, and
    supports MPLS diffserv [RFC3270]. The solution MAY support local
    policies to map the customer's reserved flow to the LSP with the
    appropriate Traffic Class at the PE.
 
 6.4  Transparency of C-RSVP Paths
 
    The solution SHOULD NOT change RSVP messages from the local CE to
    the remote CE (Path, Resv, Path Error, Resv Error, etc).
    The solution SHOULD allow customers to receive RSVP messages
    transparently between CE sites.
 
 7. Common Detailed Requirements for Two Models
 
 
 
 
 K.Kumaki, et al.                                             [Page 16]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    This section describes common detailed requirements for C-TE LSPs
    and C-RSVP paths in BGP/MPLS IP-VPN environments.
 
 7.1  CE-PE Routing
 
    The solution SHOULD support the following routing configuration on
    the CE-PE links with either RSVP or RSVP-TE on the CE-PE link:
 
    1. static routing
    2. BGP routing
    3. OSPF
    4. OSPF-TE (RSVP-TE case only)
 
 7.2  Complexity and Risks
 
    The solution SHOULD avoid introducing unnecessary complexity to
    the current operating network to such a degree that it would
    affect the stability and diminish the benefits of deploying such a
    solution over SP networks.
 
 7.3  Backward Compatibility
 
    The deployment of C-RSVP paths and C-TE LSPs SHOULD avoid
    impacting existing RSVP and MPLS TE mechanisms respectively, but
    allow for a smooth migration or co-existence.
 
 7.4  Scalability Considerations
 
    The solution SHOULD minimize the impact on network scalability
    from a C-RSVP path and a C-TE LSP over the VRF instance.
    As indentified in earlier sections, PCE provides a method for
    offloading computation of C-TE LSPs and help with the solution
    scalability.
 
    The solution MUST address the scalability of C-RSVP paths and
    C-TE LSPs for the following protocols.
 
    1. RSVP (e.g. number of RSVP messages, retained state etc).
    2. RSVP-TE (e.g. number of RSVP control messages, retained state,
    message size etc).
    3. BGP (e.g. number of routes, flaps, overloads events etc).
 
 7.5  Performance Considerations
 
    The solution SHOULD be evaluated with regard to the following
    criteria.
 
    1. Degree of path optimality of the C-TE LSP.
    2. TE LSP setup time.
 
 
 
 K.Kumaki, et al.                                             [Page 17]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    3. Failure and restoration time.
    4. Impact and scalability of the control plane due to added
       overheads.
    5. Impact and scalability of the data/forwarding plane due to
       added overheads.
 
 7.6  Management Considerations
 
    The solution MUST address the manageability of C-RSVP paths and
    C-TE LSPs for the following considerations.
 
    1. Need for a MIB module for control plane (including mapping of
        P-TE LSP and C-TE LSPs) and bandwidth monitoring.
    2. Need for diagnostic tools (this include Trace Route and PING).
 
    The solution MUST allow routers to support the MIB module for
    C-RSVP paths and C-TE LSPs per a vrf instance. If a CE is managed
    by service providers, the solution MUST allow service providers
    to collect MIB information for C-RSVP paths and C-TE LSPs from
    the CE per a customer.
 
    Diagnostic tools can detect failures of the control plane and the
    data plane for general MPLS TE LSPs [RFC4379]. The solution MUST
    allow routers to be able to detect failures of the control and
    the data plane for C-TE LSPs over a VRF instance.
 
    MPLS OAM for C-TE LSPs MUST be supported within the context of VRF
    except for the above.
 
 8.  Security Considerations
 
    Any solution should consider the following general security
    requirements:
 
    1. The solution SHOULD NOT divulge the service provider topology
       information to the customer network.
    2. The solution SHOULD minimize the service provider network
       vulnerability to Denial of Service (DoS) attacks.
    3. The solution SHOULD minimize the misconfiguration of DSCP
       marking, preemption, and holding priorities of the customer
       traffic.
 
    The following additional security issues for C-TE LSPs relate to
    both control plane and data plane.
 
    In terms of the control plane, in the models of C-RSVP paths and
    C-TE LSPs both, a PE receives IPv4 or IPv6 RSVP control packets
    from a CE. If the CE is a router that is not trusted by service
    providers, the PE MUST be able to limit the rate and number of
 
 
 
 K.Kumaki, et al.                                             [Page 18]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    IPv4 or IPv6 RSVP control packets.
 
    In terms of the data plane, in the model of C-TE LSPs, a PE
    receives labeled IPv4 or IPv6 data packets from a CE. If the CE
    is a router that is not trusted by service providers, the PE
    MUST be able to limit the rate of labeled IPv4 or IPv6 data
    packets. If the CE is a trusted router for service providers,
    the PE MAY be able to limit the rate of labeled IPv4 or IPv6
    data packets. Specifically, the PE must drop MPLS-labeled
    packets if the MPLS label was not assigned over the PE-CE link
    on which the packet was received. The PE must also be able to
    police traffic to the traffic profile associated with the LSP on
    which traffic is received on the PE-CE link.
 
    Moreover, flooding RSVP/RSVP-TE control packets from malicious
    customers must be avoided. Therefore, a PE MUST isolate the
    impact of such customer's RSVP/ RSVP-TE packets from other
    customers.
 
    In the event that C-TE LSPs are diversely routed over VRF
    instances, the VRF should indicate to the CE how such diversity
    was provided.
 
 9. IANA Considerations
 
    This requirement document makes no requests for IANA action.
 
 10. References
 
 10.1 Normative References
 
    [RFC1633]   Braden, R., et al., "Integrated Services in the
                Internet Architecture: an Overview", RFC 1633, June
                1994.
 
    [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 
    [RFC2210]   Wroclawski, J., "The Use of RSVP with IETF Integrated
                Services", RFC 2210, September 1997.
 
    [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
               V. and Swallow, G., "RSVP-TE: Extensions to RSVP for
               LSP Tunnels", RFC 3209, December 2001.
 
    [RFC3270]   Le Faucheur, F., "Multi-Protocol Label Switching
               (MPLS) Support of Differentiated Services", RFC 3270,
                May 2002.
 
 
 
 
 K.Kumaki, et al.                                             [Page 19]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    [RFC3473]  Berger, L., "Generalized Multi-Protocol Label
               Switching(GMPLS) Signaling Resource ReserVation
               Protocol-Traffic Engineering (RSVP-TE) Extensions",
               RFC 3473, January 2003.
 
    [RFC3623]   Moy, J., et al., "Graceful OSPF Restart", RFC3623,
                November 2003.
 
    [RFC4090]  Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
                Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
                2005.
 
    [RFC4124]   Le Faucheur, F., "Protocol Extensions for Support of
                Diffserv-aware MPLS Traffic Engineering", RFC 4124,
                June 2005.
 
    [RFC4364]   Rosen, E., and Rekhter, Y., "BGP/MPLS IP Virtual
                Private Networks (VPNs)", RFC 4364, February 2006.
 
    [RFC4379]   Kompella, K. and G. Swallow, "Detecting MPLS Data
                Plane Failures", RFC 4379, February 2006.
 
    [RFC4655]   Farrel, A., Vasseur, J.-P., and J. Ash, "Path
                Computation Element (PCE) Architecture", RFC 4655,
                August 2006.
 
    [RFC4781]   Rekhter, Y. and Aggarwal, R., "Graceful Restart
                Mechanism for BGP with MPLS", RFC 4781, January 2007.
 
    [RFC5036]   Andersson, L., Minei, I. and Thomas, B., "LDP
                Specification", RFC 5036, October 2007.
 
    [RFC5462]   Andersson, L. and Asati, R., "Multiprotocol Label
                Switching (MPLS) Label Stack Entry: "EXP" Field
                Renamed to "Traffic Class" Field", RFC 5462,
                February 2009.
 
 10.2 Informative References
 
    [RSVP-L3VPN]  Davie, B., et al., "Support for RSVP in Layer 3 VPNs",
                  Work in Progress, February 2008.
 
    [RFC4804]   Le Faucheur, F., et al., "Aggregation of RSVP
                Reservations over MPLS TE/DS-TE Tunnels", RFC4804,
                February 2007.
 
    [RFC5330]   Vasseur, J.-P., et al., "A Link-Type sub-TLV to convey
                the number of Traffic Engineering Label Switched Paths
                signaled with zero reserved bandwidth across a link",
 
 
 
 K.Kumaki, et al.                                             [Page 20]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
                RFC5330, October 2008.
 
    [RFC5440]   Vasseur, J.-P., et al., "Path Computation Element(PCE)
                communication Protocol (PCEP) - Version 1", RFC5440,
                March 2009.
 
 11. Acknowledgments
 
    The author would like to express the thanks to Nabil Bitar, David
    McDysan and Daniel King for their helpful and useful comments and
    feedback.
 
 12. Author's Addresses
 
    Kenji Kumaki (Editor)
    KDDI Corporation
    Garden Air Tower
    Iidabashi, Chiyoda-ku,
    Tokyo 102-8460, JAPAN
    Email: ke-kumaki@kddi.com
 
    Raymond Zhang
    BT Infonet
    2160 E. Grand Ave.
    El Segundo, CA 90025
    Email: raymond.zhang@bt.infonet.com
 
    Yuji Kamite
    NTT Communications Corporation
    Tokyo Opera City Tower
    3-20-2 Nishi Shinjuku, Shinjuku-ku
    Tokyo 163-1421, Japan
    Email: y.kamite@ntt.com
 
 Appendix A. Reference Model
 
    In this appendix, a C-RSVP path, a C-TE LSP and a P-TE LSP are
    explained.
 
    All scenarios in this appendix assume the following:
 
    - A P-TE LSP is established between PE1 and PE2. This LSP is used
      by the VRF instance to forward customer packets within a
      BGP/MPLS IP-VPN.
 
    - The Service Provider has ensured that enough bandwidth is
      available to meet the service requirements.
 
 
 
 
 
 K.Kumaki, et al.                                             [Page 21]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
 A.1 End-to-End C-RSVP Path Model
 
    A C-RSVP path and a P-TE LSP are shown in figure 1 in the context
    of a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e. LDP) in
    some cases. In the case of a non-TE mechanism, however, it may
    be difficult to guarantee an end-to-end bandwidth as resources
    are shared.
 
    CE0/CE1 requests an e2e C-RSVP path to CE3/CE2 with the bandwidth
    reservation of X. At PE1, this reservation request received in
    the context of a VRF will get aggregated onto a pre-established
    P-TE LSP, or trigger the establishment of a new P-TE LSP.
    It should be noted that C-RSVP sessions across different BGP/MPLS
    IP-VPNs can be aggregated onto the same P-TE LSP between the same
    PE pair, achieving further scalability. [RFC4804] defines this
    scenario in more detail.
 
    The RSVP control messages (e.g. an RSVP PATH message and an RSVP
    RESV message) exchanged among CEs are forwarded by IP packets
    through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive
    a reservation message from CE2 and/or CE3, CE0/CE1 establishes
    a C-RSVP path through the BGP/MPLS IP-VPN.
 
 
                                C-RSVP path
                  <------------------------------------------>
 
                                 P-TE LSP
                       <--------------------------->
      .............                                     .............
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .............                                     .............
                     ^                               ^
                     |                               |
                vrf instance                    vrf instance
 
       <-customer->    <------BGP/MPLS IP-VPN------>     <-customer->
         network                                            network
            or                                                 or
         another                                            another
      service provider                                service provider
         network                                             network
 
                        Figure 1 e2e C-RSVP path model
 
 A.2 End-to-End C-TE LSP Model
 
 
 
 
 K.Kumaki, et al.                                             [Page 22]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
    A C-TE LSP and a P-TE LSP are shown in figure 2 in the context of
    a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e. LDP) in
    some cases. As described in previous sub-section, it may be
    difficult to guarantee an end-to-end QoS in some cases.
 
    CE0/CE1 requests an e2e TE LSP path to CE3/CE2 with the bandwidth
    reservation of X. At PE1, this reservation request received in the
    context of a VRF will get aggregated onto a pre-established P-TE
    LSP, or trigger the establishment of a new P-TE LSP. It should be
    noted that C-TE LSPs across different BGP/MPLS IP-VPNs can be
    aggregated onto the same P-TE LSP between the same PE pair,
    achieving further scalability.
 
    The RSVP-TE control messages (e.g. a RSVP PATH message and a RSVP
    RESV message) exchanged among CEs are forwarded by a labeled
    packet through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive
    a reservation message from CE2 and/or CE3, CE0/CE1 establishes a
    C-TE LSP through the BGP/MPLS IP-VPN.
 
    A P-TE LSP is established between PE1 and PE2. This LSP is used
    by the VRF instance to forward customer packets within the
    BGP/MPLS IP-VPN.
 
                                  C-TE LSP
         <------------------------------------------------------->
 
                                     or
 
                                  C-TE LSP
                <----------------------------------------->
 
                                  P-TE LSP
                       <--------------------------->
      .............                                     .............
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
      . ---   --- .   ---      ---       ---      ---   . ---   --- .
      .............                                     .............
                     ^                               ^
                     |                               |
                vrf instance                    vrf instance
 
       <-customer->   <-------BGP/MPLS IP-VPN------->    <-customer->
         network                                            network
            or                                                 or
         another                                            another
     service provider                                 service provider
         network                                            network
 
 
 
 
 K.Kumaki, et al.                                             [Page 23]
 

                 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05   December 2009
 
                         Figure 2 e2e C-TE LSP model
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 K.Kumaki, et al.                                             [Page 24]
 

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/