[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                         M Bocci
Internet Draft                                                Alcatel

                                                             S.Bryant
                                                         Cisco Systems

Expires: January 2006                                     July 9, 2005



    An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge



                 draft-bocci-bryant-pwe3-ms-pw-arch-00.txt




Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   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 December 1, 2005.





Bocci et al            Expires January 9, 2006                [Page 1]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This document describes an architecture for extending pseudo wire
   emulation across multiple packet switched network segments. Scenarios
   are discussed where each segment of a given edge-to-edge emulated
   service spans a different provider's PSN, and where the emulated
   service originates and terminates on the same providers PSN, but may
   pass through several PSN tunnel segments in that PSN. It presents an
   architectural framework for such multi-segment pseudo wires, defines
   terminology, and specifies the various protocol elements and their
   functions.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].

Table of Contents


   1. Introduction................................................3
      1.1. Motivation.............................................3
      1.2. Non-Goals of this Document..............................6
      1.3. Terminology............................................6
   2. Applicability...............................................7
   3. Protocol Layering model......................................7
      3.1. Domain of Multi-Segment PWE3............................7
      3.2. Payload Types..........................................8
   4. Multi-Segment PWE3 Reference Model...........................8
      4.1. Intra-Provider Architecture.............................9
      4.2. Inter-Provider Architecture.............................9
      4.3. PW Switching Models....................................10
         4.3.1. Switching using ACs...............................10
         4.3.2. Switching using PWs...............................10
   5. PE Reference Model.........................................10
      5.1. PWE3 Pre-processing....................................10
         5.1.1. Forwarding........................................11
         5.1.2. Native Service Processing.........................11
   6. Protocol Stack reference Model..............................11
   7. Maintenance Reference Model.................................12
   8. PW Demultiplexer Layer and PSN Requirements.................12
   9. Control Plane..............................................12


Bocci & Bryant         Expires January 9, 2006                [Page 2]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


   10. Fragmentation.............................................13
   11. Management and Monitoring..................................13
   12. IANA Considerations........................................13
   13. Security Considerations....................................13
   14. Acknowledgments...........................................13
   15. References................................................14
      15.1. Normative References..................................14
   Author's Addresses............................................14
   Intellectual Property Statement................................14
   Disclaimer of Validity........................................15
   Copyright Statement...........................................15
   Acknowledgment................................................15

1. Introduction

   RFC 3985 [2] defines the architecture for pseudo wires, where a
   pseudo wire (PW) both originates and terminates on the edge of the
   same packet switched network (PSN). The PW passes through a maximum
   of one PSN tunnel between the originating and terminating PEs.

   This document extends the architecture in RFC 3985 to enable pseudo
   wires to be extended through multiple PSN tunnels. Use cases for
   multi-segment pseudo wires, and the consequent requirements, are
   defined in [3].

1.1. Motivation

   PWE3 aims to provide point-to-point connectivity between two edges of
   a provider network. Requirements for Multi-Segment Pseudo-Wires for
   this are specified in [3]. These requirements address three main
   problems:

   o How to scale PWE3 when the number of PEs grows to many hundreds or
      thousands, while minimizing the complexity of the PEs and P
      routers.

   o How to provide PWE3 across multiple PSN routing domains or areas
      in the same provider.

   o How to provide PWE3 across multiple provider domains, and
      different PSN types.

   Consider a single PWE3 domain, such as that shown in Figure 1. There
   are 4 PEs, and PWE3 must be provided from any PE to any other PE.
   Traditionally, this would be achieved by establishing a full mesh of
   PSN tunnels between the PEs. This would also require a full mesh of
   LDP signaling adjacencies between the PEs. Pseudo wires could then be


Bocci & Bryant         Expires January 9, 2006                [Page 3]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


   established between any PE and any other PE via a single, direct
   tunnel. PEs must terminate all pseudo wires that are carried on PSN
   tunnels that terminate on that PE according to the architecture of
   RFC 3985. This solution is adequate for small numbers of PEs, but the
   number of PEs and signaling adjacencies will grow in proportion to
   the square of the number of PEs.

   A more efficient solution for large numbers of PEs would be to
   support a partial mesh of PSN tunnels between the PEs, as shown in
   Figure 1. For example, consider a PWE3 service whose endpoints are
   PE1 and PE4. Pseudo wires for this can take the path PE1->PE2->PE3,
   and rather than terminating at PE2, be switched between ingress and
   egress PSN tunnels on that PE. This requires a capability in PE2 that
   can concatenate PW segments PE1-PE2 to PW segments PE2-PE3. The end-
   to-end PW is known as a multi-segment PW.

                                ,,..--..,,_
                            .-``           `'.,
                    +-----+`                   '+-----+
                    | PE1 |---------------------| PE2 |
                    |     |---------------------|     |
                    +-----+      PSN Tunnel     +-----+
                    / ||                          || \
                   /  ||                          ||  \
                  |   ||                          ||   |
                  |   ||         PSN              ||   |
                  |   ||                          ||   |
                   \  ||                          ||  /
                    \ ||                          || /
                     \||                          ||/
                    +-----+                     +-----+
                    | PE3 |---------------------| PE4 |
                    |     |---------------------|     |
                    +-----+`'.,_           ,.'` +-----+
                                `'''---''``
                     Figure 1 Single PSN PWE3 Scaling

   Figure 1 shows a simple flat PSN topology. However, large provider
   networks are typically not flat, consisting of many domains that are
   connected together to provide edge-to-edge services. The elements in
   each domain are specialized for a particular role.

   An example application is shown in Figure 2. Here, the providers
   network is divided into three domains: Two access domains and the
   core domain. The access domains represent the edge of the provider's
   network at which services are delivered. In the access domain,
   simplicity is required in order to minimize the cost of the network.


Bocci & Bryant         Expires January 9, 2006                [Page 4]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


   The core domain must support all of the aggregated services from the
   access domains, and the design requirements here are for scalability,
   performance, and information hiding (i.e. minimal state). The core
   must not be exposed to the state associated with large numbers of
   individual edge-to-edge flows. That is, the core must be simple and
   fast.

   In a traditional layer 2 network, the interconnection points between
   the domains are where services in the access domains are aggregated
   for transport across the core to other access domains. In an IP
   network, the interconnection points would also represent interworking
   points between different types of IP networks e.g. those with MPLS
   and those without, and also points where network policies can be
   applied.

       <----------------Edge to Edge Emulated Services--------->


                .-.,          ,..-..,            .-.,
              ,'    .      ,-`       `',       ,'    .
             /       \   .`             `,    /       \
            /        \  /                 ,  /        \
     AC  +----+     +----+               +----+       +----+    AC
      ---| PE |=====| PE |===============| PE |=======| PE |---
         |  1 |     |  2 |               | 3  |       | 4  |
         +----+     +----+               +----+       +----+
            \        /  \                 /  \        /
             \       /  \      Core       `   \       /
              `,    `    '.             ,`     `,    `
                '-'`       `.,       _.`         '-'`
             Access 1         `''-''`         Access 2

                    Figure 2 Multi-Domain Network Model

   This model can also be applied to inter-provider services, where they
   also rely on a number of separate provider networks to be connected
   together.

   Consider the application of this model to PWE3. PWE3 uses tunneling
   mechanisms such as MPLS to enable the underlying IP PSN to emulate
   characteristics of the native service. One solution to the multi-
   domain network model above is to extend PSN tunnels edge-to-edge
   between all of the PEs in access domain 1 and all of the PEs in
   access domain 2, but this runs into the scaling issues described
   above, and also exposes access and the core of the network to
   undesirable complexity. An alternative is to constrain the complexity
   to the network domain interconnection points (PE2 and PE3 in the


Bocci & Bryant         Expires January 9, 2006                [Page 5]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


   example above). Pseudo-wires between PE1 and PE4 would then be
   switched between PSN tunnels at the interconnection points, enabling
   PWs from may PEs in the access domains to be aggregated across only a
   few PSN tunnels in the core of the network. PEs in the access domains
   would only need to maintain direct signaling sessions, and PSN
   tunnels, with other PEs in their own domain, thus minimizing
   complexity of the access domains.

1.2. Non-Goals of this Document

   The following are non-goals for this document:

   o The on-the-wire specification of PW encapsulations

   o Requirements on multi-segment pseudo-wires.

   o The detailed specification of mechanisms for establishing and
      maintaining multi-segment pseudo-wires.

1.3. Terminology

   The terminology specified in RFC 3985 applies. In addition, we define
   the following terms:

   o Ultimate PE (U-PE).  A PE where the customer-facing attachment
      circuits (ACs) are bound to a PW forwarder. An ultimate PE is
      present in the first and last segments of a MS-PW.

   o Single-Segment PW (SS-PW). A PW setup directly between two U-PE
      devices. Each PW in one direction of a SS-PW traverses one PSN
      tunnel that connects the two U-PEs.

   o Multi-Segment PW (MS-PW).  A static or dynamically configured set
      of two or more contiguous PW segments that behave and function as
      a single point-to-point PW. Each end of a MS-PW by definition MUST
      terminate on a U-PE.

   o PW Switching Provider Edge (S-PE).  A PE capable of switching the
      control and data planes of the preceding and succeeding PW
      segments in a MS-PW. It is therefore a PW switching point for a
      MS-PW. A PW Switching Point is never the S-PE and the U-PE for the
      same MS-PW. A PW switching point runs necessary protocols to setup
      and manage PW segments with other PW switching points and ultimate
      PEs.

   o PW Segment. A part of a single-segment or multi-segment PW, which
      is set up between two PE devices, U-PEs and/or S-PEs.


Bocci & Bryant         Expires January 9, 2006                [Page 6]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


2. Applicability

   A MS-PW is a single PW that for technical or administrative reasons
   is segmented into a number of concatenated hops. From the
   perspective of a U-PE, a MS-PW is indistinguishable from a SS-PW.
   Thus, the following are equivalent from the perspective of the UPE

       +----+                                                  +----+
       |UPE1+--------------------------------------------------+UPE2|
       +----+                                                  +----+

            |<----------------------PW------------------------>|

       +----+              +---+           +---+               +----+
       |UPE1+--------------+SPE+-----------+SPE+---------------+UPE2|
       +----+              +---+           +---+               +----+


                      Figure 3     MS-PW Equivalence

   Although a MS-PW may require services such as node discovery and path
   signaling to construct the PW, it should not be confused with a L2VPN
   system, which also requires these services. A VPWS connects its
   endpoints via a set of PWs. MS-PW is a mechanism that abstracts the
   construction of complex PWs from the construction of a L2VPN. Thus a
   U-PE might be an edge device optimized for simplicity and an S-PE
   might be an aggregation device designed to absorb the complexity of
   continuing the PW across the core of one or more service provider
   networks to another UPE located at the edge of the network.

3. Protocol Layering model

   The protocol-layering model specified in RFC 3985 applies to multi-
   segment PWE3 with the following clarification: the pseudo-wires may
   be considered to be a separate layer to the PSN tunnel. That is, they
   are independent of the PSN tunnel routing, operations, signaling and
   maintenance. The design of PW routing domains should not imply that
   the underlying PSN routing domains are the same. However, MS-PW will
   reuse the protocols of the PSN.

3.1. Domain of Multi-Segment PWE3

   PWE3 defines the Encapsulation Layer, the method of carrying various
   payload types, and the interface to the PW Demultiplexer Layer. It
   is expected that other layers will provide the following:

      . PSN tunnel setup, maintenance and routing


Bocci & Bryant         Expires January 9, 2006                [Page 7]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


      . U-PE discovery

   It is assumed that any node that is reachable via a PSN tunnel from
   an S-PE or U-PE is a PE, a subset of which may be capable of behaving
   as an S-PE. The selection of which S-PEs to use to reach a U-PE is
   considered to be in the domain of PWE3.

3.2. Payload Types

   Multi-segment PWE3 is applicable to all PWE3 payload types. The same
   encapsulations are used in both SS-PW and MH-PW.

4. Multi-Segment PWE3 Reference Model

   The PWE3 reference architecture for the single segment case is shown
   in [2]. This architecture applies to the case where a PSN tunnel
   extends between two edges of a single PSN domain to transport a PW
   with endpoints at these edges.



       Native   |<-----------Pseudo Wire----------->|  Native
       Service  |                                   |  Service
        (AC)    |    |<-PSN1-->|     |<-PSN2-->|    |   (AC)
          |     V    V         V     V         V    V     |
          |     +----+         +-----+         +----+
   +----+ |     |UPE1|=========|SPE1 |=========|UPE2|     |    +----+
   |    |-------|....PW.Seg't1........PW Seg't3.....|----------|    |
   | CE1| |     |    |         |     |         |    |     |    |CE2 |
   |    |-------|....PW.Seg't2.......|PW Seg't4.....|----------|    |
   +----+ |     |    |=========|     |=========|    |     |    +----+
     ^          +----+         +-----+         +----+          ^
     |      Provider Edge 1       ^        Provider Edge 2     |
     |                            |                            |
     |                            |                            |
     |                    PW switching point                   |
     |                                                         |
     |<------------------- Emulated Service ------------------>|

                   Figure 4 PW switching Reference Model

   Figure 4 extends this architecture to show a multi-segment case. The
   PEs that provide PWE3 to CE1 and CE2 are Ultimate-PE1 (U-PE1) and
   Ultimate-PE2 (U-PE2) respectively. A PSN tunnel extends from U-PE1 to
   switching-PE1 (S-PE1) across PSN1, and a second PSN tunnel extends
   from S-PE1 to S-PE2 across PSN2. PWs are used to connect the
   attachment circuits (ACs) attached to PE1 to the corresponding ACs


Bocci & Bryant         Expires January 9, 2006                [Page 8]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


   attached to PE3. Each PW segment on the tunnel across PSN1 is
   switched to a PW segment in the tunnel across PSN2 at S-PE1 to
   complete the multi-segment PW (MS-PW) between U-PE1 and U-PE2. S-PE1
   is therefore the PW switching point. PW segment 1 and PW segment 3
   are segments of the same MS-PW while PW segment 2 and PW segment 4
   are segments of another MS-PW. PW segments of the same MS-PW (e.g.,
   PW1 and PW3) MAY be of the same PW type or different type, and PSN
   tunnels (e.g., PSN1 and PSN2) can be the same or different
   technology. This document requires support for MS-PWs with segments
   of the same type. An S-PE switches an MS-PW from one segment to
   another based on the PW identifiers (e.g., PW label in case of MPLS
   PWs).

   Note that although Figure 4 only shows a single S-PE, a PW may
   transit more one S-PE along its path. This architecture is applicable
   when the S-PEs are statically chosen, or when they are chosen using a
   dynamic path selection mechanism.

4.1. Intra-Provider Architecture

   There is a requirement to deploy PWs edge to edge in large
   service provider networks [3]. Such networks typically encompass
   hundreds or thousands of aggregation devices at the edge, each of
   which would be a PE. These networks may be partitioned into separate
   metro and core PWE3 domains, where the PEs are interconnected by a
   sparse mesh of tunnels.

   Whether or not the network is partitioned in to separate PWE3
   domains, there is a also a requirement to support a partial mesh of
   traffic engineered PSN tunnels.

   The architecture shown in Figure 4 can be used to support such cases.
   PSN1 and PSN2 may be in different administrative domains or access,
   core or metro regions within the same providers network.
   Alternatively, U-PE1, SPE1 and U-PE2 may reside at the edges of the
   same PSN.

4.2. Inter-Provider Architecture

   Intra-provider PWs may need to be switched between PSN tunnels at the
   provider boundary in order to minimize the number of tunnels required
   to provide PWE3 services to CEs attached to each providers network.
   In addition, AAA and security and mechanisms may need to be
   implemented on a per-PW basis at the provider boundary.





Bocci & Bryant         Expires January 9, 2006                [Page 9]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


4.3. PW Switching Models

4.3.1. Switching using ACs.

   In this model, the PW reverts to the native service at the provider
   boundary PE. This AC is then connected to a separate PW at the peer
   provider boundary PE. In this case, the reference models of RFC 3965
   apply to each segment and to the PEs. The remaining PE architectural
   considerations in this document do not apply to this case.

4.3.2. Switching using PWs.

   In this model, PW segments are switched between PSN tunnels in each
   providers network, without reverting to the native service at the
   boundary. For example, in Figure 4, PSN 1 and PSN 2 would be
   different provider's networks. However, this would require that S-PE1
   be a member of both provider networks.

   An alternative architecture is shown in Figure 5.

                   |<--------------Pseudo Wire----------->|
                   |       Provider         Provider      |
               AC  |    |<----1---->|     |<----2--->|    |  AC
               |   V    V           V     V          V    V  |
               |   +----+     +-----+     +----+     +----+  |
      +----+   |   |    |=====|     |=====|    |=====|    |  |    +----+
      |    |-------|.....PW.1........PW.2.......PW.3......|-------|    |
      | CE1|   |   |    |     |     |     |    |     |    |  |    |CE2 |
      +----+   |   |    |=====|     |=====|    |=====|    |  |    +----+
           ^       +----+     +-----+     +----+     +----+       ^
           |         PE1        PE2        PE3         PE4        |
           |                     ^          ^                     |
           |                     |          |                     |
           |                  PW switching points                 |
           |                                                      |
           |                                                      |
           |<------------------- Emulated Service --------------->|


                  Figure 5 Inter-Provider Reference Model

5. PE Reference Model

5.1. PWE3 Pre-processing

   PWE3 preprocessing is applied in the U-PEs as specified in RFC 3985.
   Processing at the S-PEs is specified in the following sections.


Bocci & Bryant         Expires January 9, 2006               [Page 10]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


5.1.1. Forwarding

   The forwarders in the S-PE forward packets from one or more PW
   segments on the ingress PSN facing interface of the S-PE to one or
   more PW segments on the egress PSN facing interface of the S-PE.

   The forwarder selects the egress segment PW based on the ingress PW
   label. The mapping of ingress to egress PW label may be statically or
   dynamically configured. Figure 5 shows how a single forwarder is
   associated with each PW segment at the S-PE.

               +------------------------------------------+
               |                S-PE Device               |
               +------------------------------------------+
     Ingress   |             |             |              |   Egress
   PW instance |   Single    |             |    Single    | PW Instance
   <==========>X PW Instance +  Forwarder  + PW Instance  X<==========>
               |             |             |              |
               +------------------------------------------+

                      Figure 6 Point-to-Point Service

   Other mappings of PW to forwarder are for further study.

5.1.2. Native Service Processing

   There is no native service processing in the S-PEs.

6. Protocol Stack reference Model

   Figure 7 illustrates the protocol stack reference model for multi-
   segment PWs.
















Bocci & Bryant         Expires January 9, 2006               [Page 11]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


+----------------+                                  +----------------+
|Emulated Service|                                  |Emulated Service|
|(e.g., TDM, ATM)|<======= Emulated Service =======>|(e.g., TDM, ATM)|
+----------------+                                  +----------------+
|    Payload     |                                  |    Payload     |
|  Encapsulation |<== Multi-segment Pseudo Wire ===>|  Encapsulation |
+----------------+            +--------+            +----------------+
|PW Demultiplexer|<PW Segment>|PW Demux|<PW Segment>|PW Demultiplexer|
+----------------+            +--------+            +----------------+
|   PSN Tunnel,  |<PSN Tunnel>|   PSN  |<PSN Tunnel>|  PSN Tunnel,   |
| PSN & Physical |            |Physical|            | PSN & Physical |
|     Layers     |            | Layers |            |    Layers      |
+-------+--------+            +--------+            +----------------+
        |            ..........   |   ..........            |
        |           /          \  |  /          \           |
        +==========/     PSN    \===/    PSN     \==========+
                   \  domain 1  /   \  domain 2  /
                    \__________/     \__________/
                     ``````````       ``````````

                 Figure 7 Multi-Segment PW Protocol Stack

   The MS-PW provides the CE with an emulated physical or virtual
   connection to its peer at the far end. Native service PDUs from the
   CE are passed through an Encapsulation Layer and a PW demultiplexer
   is added at the sending U-PE. The PDU is sent over PSN domain 1. The
   receiving S-PE removes the existing PW demultiplexer, adds a new
   demultiplexer, and then sends the PDU over PSN2. Policies may also be
   applied to the PW at this point. The receiving U-PE removes the PW
   demultiplexer and restores the payload to its native format for
   transmission to the destination CE.

   Where the encapsulation format is different e.g. MPLS and L2TPv3, the
   payload encapsulation may be transparently translated at the S-PE.

7. Maintenance Reference Model

   To be added in a future version.

8. PW Demultiplexer Layer and PSN Requirements

   To be added in a future version.

9. Control Plane

   For multi-segment pseudo wires, the intermediate PW switching points
   may be statically provisioned, or they may be dynamically signaled.


Bocci & Bryant         Expires January 9, 2006               [Page 12]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


   For the dynamic case, there are two options for selecting the path of
   the PW:

   o U-PEs determine the full path of the PW through intermediate
      switching points. This may be either static or based on a dynamic
      PW path selection mechanism.

   o The each segment of the PW path is determined locally by each U-PE
      or S-PE, either through static configuration or based on a dynamic
      PW path selection mechanism.

   Further details of the impact of these on the control plane
   architecture will be provided in a future revision.

10. Fragmentation

An SPE is not required to make any attempt to reassemble a fragmented PW
payload. An SPE may fragment a PW payload fragment.

11. Management and Monitoring

   To be added in a later version.

12. IANA Considerations

   To be added in a future version.

13. Security Considerations

   To be added in a later version.

14. Acknowledgments

   The authors gratefully acknowledge the input of Mustapha Aissaoui,
   Dimitri Papadimitrou, and Luca Martini.













Bocci & Bryant         Expires January 9, 2006               [Page 13]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


15. References

15.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]  Bryant, S. and Pate, P. (Editors), "Pseudo Wire Emulation Edge-
         to-Edge (PWE3) Architecture", RFC 3985, March 2005

   [3]  Martini, S. Bitar, N. and Bocci, M (Editors), "Requirements for
         inter domain Pseudo-Wires", draft-martini-pwe3-mh-pw-
         requirements-01.txt, internet Draft, March 2005



Author's Addresses

   Matthew Bocci
   Alcatel
   Voyager Place,
   Shoppenhangers Rd,
   Maidenhead, Berks, UK    Email: matthew.bocci@alcatel.co.uk


   Stewart Bryant
   Cisco Systems,
   250, Longwater,
   Green Park,
   Reading, RG2 6GB,
   United Kingdom.             Email: stbryant@cisco.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an


Bocci & Bryant         Expires January 9, 2006               [Page 14]


Internet-Draft     Multi-Segment PWE3 Architecture           July 2005


   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf
   ipr@ietf.org

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















Bocci & Bryant         Expires January 9, 2006               [Page 15]