Subject: RE: [PWE3] Generic PW - Is there a need?

From: "Florin Balus" <[email-masked]>
Date: Fri, 17 Feb 2006 06:05:44 -0500

Sasha,
That is what we proposed in the IP PW draft - see enclosed... Granted we
need to update the encoding of the fields to match the evolution of the
CW draft.

Luca, Peter,
Replying to your comments: on top of the regular native AC use case (ETH
to ATM/FR etc) with an IP PW in the middle I thought people wanted with
the generic PW initiative to push the PW encapsulation down to the CE
router in either an entreprise or a Carrier of Carrier use case. That is
to benefit from a common service layer end to end: no more translation
between native AC and PW will benefit the OAM etc, ARP mediation will go
away etc... 

The topology will look something like this:

CE1 (SP1/Entreprise) PW uplink - SS1-PW AC on PE2 (w/ Seg PWs in SP2
netw) -- PSN (SP2) -- PE3 (w/ Seg PWs - SP2) SS3-PW AC - PW Uplink on
CE4 (SP1/Entreprise)

CE1 and CE4 may be routers or even PEs in their own network and do not
need to have control plane exchanges with PE2/PE3 (although they may run
E-LDP). They are just getting a L2 VC based on a PW/LSP format from SP1
and they can do whatever they want with it for a true data VC: e.g. run
IP+IS-IS on top of it if they want to instead of buying multiple PWs
from SP1 and worry about fate sharing etc (all the stuff that Sasha
mentioned below). 

I know this is against conventional wisdom of this times but maybe worth
investigating if people see value in considering this use case. 

>-----Original Message-----
>From: Sasha Vainshtein [mailto:[email-masked]] 
>Sent: Friday, February 17, 2006 2:55 AM
>To: 'Luca Martini '; Balus, Florin [CAR:6955:EXCH]
>Cc: 'pwe3 pwe3 '; 'Danny McPherson '
>Subject: RE: [PWE3] Generic PW - Is there a need?
>
>
>Luca, Florin and all,
>Sorry for a possibly naive question, but did anybody consider 
>carrying IS-IS along an IP PW using the Associated Channel 
>mechanism defined in draft-ietf-pwe3-cw-06.txt and allocating 
>a dedicated Channel Type in the appropriate IANA registry?
>
>In this way:
>- fate-sharing of IP and IS-IS packets along the PW would be guaranteed
>- potential MS-PW issues could be handled in a generic manner
>- performance would not be an issue (presumably IS-IS traffic is
>  negligible when compared with the IP traffic)
>- It would be possible (and easy) for a pair of PEs to negotiate
>  specific Associated Channel Type(s) they support during the setup
>  by adding an appropriate Interface Parameter sub-TLV thus making it
>  a scalable approach (at least,as long as we are talking about some
>  control protocols accompanying data and not about true "data"
>  multi-protocol.
>
>It would be interesting to see which use case for the generic 
>packet PW would remain unresolved.
>
>My 2 c.
>
>Regards,
>                 Sasha
>
>
>
>-----Original Message-----
>From: Luca Martini
>To: Florin Balus
>Cc: pwe3 pwe3; Danny McPherson
>Sent: 2/16/2006 8:53 PM
>Subject: Re: [PWE3] Generic PW - Is there a need?
>
>Florin Balus wrote:
>>
>> I believe there is a need for a multiprotocol PW as we want 
>some flows 
>> to share really the same path: i.e. I want the IP data packets to
>follow
>> the same path as the IS-IS protocol that provides the routing
>exchanges.
>> There could be also simplifications related to the fact that an 
>> enterprise customer will not need to buy different PWs for each 
>> encapsulation if the resulted connections go between the 
>same 2 sites: 
>> IPv4, IPv6, IS-IS etc... Think also about PWs as uplinks for Managed
>CE
>> <Virtual> Routing not only just for ACs...
>>
>>   
>
>Are you talking about having some kind of layer3 PW ?
>what next ? a TCP PW , an UDP PW , and a Rip PW ?
>
>The IS-IS case is a black sheep indeed , as we are using an non IP 
>protocol to route IP.
>As I explained before the answer for that is to use the true layer2 
>protocol, not an IP PW.
>
>Luca
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Mon, 20 Feb 2006 09:25:43 -0700

Florin,

This idea has been around for 8 years. Since when MPLS was first noticed 
, the first thing I heard from my marketing folks at the time was "Can 
we sell an MPLS UNI ? "

Over the years it became apparent that the application is routed  IP, 
and the L2 technology between the CE and the PE does not really matter 
all that much.
The interworking cases that spawned this IP PW technology where 
justified by either migration scenarios, or regulatory rules that 
somebody was attempting to circumvent.
The example you give below is very much like a frame relay pvc. So why 
would be create new protocols , or modify existing one to fit an 
application  that is well served by existing technology ?
I believe that the IP PW has it's application to facilitate interworking 
, but I doubt it would be useful as a PW MPLS UNI .

Luca

Florin Balus wrote:
>> ------------------------------------------------------------------------
>>
>>
>>
>>  PWE3 Working Group
>>  Internet Draft
>>  Expires: April 2005
>>
>>  Himanshu Shah                                   Florin Balus
>>  Ciena Networks                                  Mike Loomis
>> 								 Jeff Sugimoto                                                
>> 								 Nortel Networks
>>  Mustapha Aissaoui							 
>>  Alcatel    						 Mircea Pisica
>>  								 Infonet
>>
>>                                                  October 2004
>>
>>
>>                        IP Pseudowire Encapsulation
>>
>>                   draft-balus-pwe3-ip-pseudowire-01.txt
>>
>>
>>  Status of this Memo
>>
>>     By submitting this Internet-Draft, I certify that any applicable 
>>     patent or other IPR claims of which I am aware have been disclosed,
>>     or will be disclosed, and any of which I become aware will be 
>>     disclosed, in accordance with RFC 3668.
>>
>>     This document is an Internet-Draft and is in full conformance with
>>     all provisions of Section 10 of RFC2026.
>>     Internet-Drafts are working documents of the Internet Engineering
>>     Task Force (IETF), its areas, and its working groups.  Note that
>>     other groups may also distribute working documents as Internet-
>>     Drafts.
>>
>>     Internet-Drafts are draft documents valid for a maximum of six
>>     months and may be updated, replaced, or obsoleted by other documents
>>     at any time.  It is inappropriate to use Internet-Drafts as
>>     reference material or to cite them other than as "work in progress."
>>
>>     The list of current Internet-Drafts can be accessed at
>>          http://www.ietf.org/ietf/1id-abstracts.txt
>>     The list of Internet-Draft Shadow Directories can be accessed at
>>          http://www.ietf.org/shadow.html.
>>
>>  Abstract
>>
>>     This document proposes a PW encapsulation specific to IP packets,
>>     the IP Pseudowire, following the architectural principles defined in 
>>     [PWE3 Architecture]. This proposal introduces an optional CW for IP 
>>     encapsulation. Note that when the inclusion of a control word is not 
>>     negotiated, the IP PW uses the encapsulation described in [RFC3032].
>>
>>  Balus et.al            Expires Jan 2005                     Page 1 
>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires January 2005
>>
>>  Table of Contents
>>
>>  1.    Conventions used in this document.............................2
>>  2.    Introduction and Requirements.................................2
>>  3.    Reference Model...............................................3
>>  4.    IP PW Encapsulation...........................................4
>>  5.    Support for PW OAM............................................5
>>  6.    Support for non-IP payload....................................6
>>  7.    Signaling of the IP PW........................................7
>>  8.    Security Considerations.......................................7
>>  9.	 Changes from the previous version.............................7
>>  10.   Acknowledgements..............................................7
>>  11.   Intellectual Property Rights Notices..........................7
>>  12.   References....................................................7
>>  13.   Authors' Addresses............................................8
>>
>>  1. Conventions used in this document
>>     The keywords "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
>>
>>  2. Introduction and Requirements
>>
>>     This document defines the encapsulation and the motivators for using an 
>>     optional CW for IP pseudowire. In this model, the AC circuits are 
>>     terminated at each PE, and only the IP payload is transported across the 
>>     PSN using a PW header. Two solutions using the IP PW encapsulation 
>>     are described in [ARP Mediation] and [IPLS]. Multi-hop pseudowire could be  
>>     also another application for the concepts described in this draft.
>>     
>>     The requirements for an IP PW vary depending on the behavior expected 
>>     from end user application, and sometimes by how much the layer 2 media 
>>     characteristics were used to achieve said behaviour. For instance, 
>>     deterministic path forwarding, connection tracing, discard priorities 
>>     and congestion notifications are typical L2 attributes, which often 
>>     benefit a native, end-to-end service encapsulated within it. In the 
>>     context of an IP PW, these characteristics may need to be reflected to 
>>     preserve current SLAs.
>>
>>     Specifically concerning deterministic path forwarding in IP/MPLS networks, 
>>     when no CW is used, the IP PW uses the encapsulation described in 
>>     [RFC3032], virtually indistiguishable from the IP over MPLS encapsulation, 
>>     mapped based on the IP FEC. Current ECMP algorithms used by the MPLS LSRs 
>>     may perform deep packet inspection and loadshare the IP over MPLS packets 
>>     based on the IP addresses from the customer IP header. As a result, when 
>>     the CW is not present, the packets on an IP PW may be loadspread across 
>>     multiple backbone paths compromising the deterministic path forwarding. 
>>     In this scenario potential OAM packets (see [VCCV]) may be forwarded 
>>     consistently on a different path than most of the IP PW packets. This 
>>     could cause challenges for troubleshooting and operational changes to the
>>     network administrator looking to migrate their L2VPN networks to an IP PW 
>>
>>  Balus et.al                                                     Page 2
>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires January 2005
>>
>>     transport. Network operators that relied on L2 mechanisms to provide this 
>>     functionality may expect to preserve this behavior in IP PWs. Similarly, 
>>     some end user applications rely on native L2 congestion notifications or 
>>     discard priority markings for QoS treatment or even SLA reporting. 
>>     
>>     Clearly, not all end user applications using an IP PW will have an 
>>     identical set of requirements. Typically an internet access service has 
>>     less requirements from its layer 2 transport media, when compared to a 
>>     SLA-based, L2VPN service. An IP PW must be flexible enough to satisfy the 
>>     loose requirements of the basic application, but offer the optional tools 
>>     to address the strict requirements of the more demanding one.These 
>>     requirements typically include:
>>      ·  Enable the use of PW in-band OAM with or without ECMP
>>      ·  Distinguish an IP PW frame from a regular IP/MPLS frame for 
>> 	   consistent forwarding of user frames in a PSN using ECMP
>>      ·  The option to reflect important layer 2 service characteristics 
>> 	
>>     This document proposes an IP PW encapsulation that includes an optional 
>>     IP control word. The new encapsulation enables the use of PW OAM tools 
>>     already defined in [VCCV] while offering the mechanisms for preserving the
>>     characteristics of the end-to-end L2 service. This provides an efficient 
>>     transport of IP PDUs between ACs in environment where ECMP is deployed but 
>>     the lack of determinism of ECMP, and diagnostic complexity is not desired 
>>     for this specific service. The document describes also how the proposed 
>>     solution addresses the case of an MPLS backbone running ECMP so that the 
>>     data and OAM packets follow the same path throughout the backbone.
>>
>>  3. Reference Model
>>
>>     The following diagram represents the reference model used to
>>     describe the services emulated by the IP PW, based on the concepts
>>     outlined in [PWE3 Architecture].
>>              |<------------- Emulated L2 Service -------------->|
>>              |                                                  |
>>              |          |<----- IP Pseudo Wire ----->|          |
>>              |          |                            |          |
>>              |          |    |<-- PSN Tunnel -->|    |          |
>>              |          V    V                  V    V          |
>>              V(IP/)X AC +----+                  +----+(IP/)Y AC V
>>        +-----+    |     | PE1|==================| PE2|     |    +-----+
>>        |     |----------|..........IP PW1............|----------|     |
>>        | CE1 |    |     |    |                  |    |     |    | CE2 |
>>        |     |----------|..........IP PW2............|----------|     |
>>        +-----+  ^ |     |    |==================|    |     | ^  +-----+
>>              ^  |       +----+                  +----+     | |  ^
>>              |  |   Provider Edge 1         Provider Edge 2  |  |
>>        Customer |                                            | Customer
>>        Edge 1   |                                            | Edge 2
>>                 |                                            | 
>>          native X service                             native Y service
>>                     Figure 1: PWE3 IP PW Network Reference Model
>>
>>  Balus et.al                                                     Page 3 
>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires January 2005
>>
>>     In figure 1, X and Y represent two Attachment Circuits, both 
>>     upporting an IP payload. An IP PW is used to provide PSN transport 
>>     between the two ACs. It is important to note as a general rules that 
>>     for the direction CE1 to CE2 the ingress PE, PE1, should map all the 
>>     IP/X frames to IP/PW encapsulation described in section 4. The rest 
>>     of the frame types MUST be discarded with the exceptions noted in 
>>     section 7. Same is valid in the reverse direction (CE2->CE1) on PE2.
>>
>>  4. IP PW Encapsulation
>>
>>     This document introduces an OPTIONAL Control Word (CW) in front of
>>     the customer IP payload. This will address the requirements
>>     described in section 2, ensuring that the IP PW data packets follow 
>>     the same path with the PW OAM ones. Also the presence of this CW 
>>     allows for additional flexibility in maintaining the Layer 2 service 
>>     characteristics.
>>
>>     The IP PW Control Word follows the guidelines and the bit format
>>     described in [Martini L2CIRC] section 3.1 - see figure 3 below:
>>     
>>         0                   1                   2                   3
>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        | Rsvd  |B|F|D|0|FRG|   Length  |           Sequence            |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |                      Customer IP PDU                          |
>>        |                             "                                 |
>>        |                             "                                 |
>>        |                             "                                 |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>                         Figure 3: IP PW Control Word
>>
>>     - The first 4 bits are reserved for further use. They MUST be set to
>> 	(0000) upon transmitting. They ensure the IP PW data packets are 
>> 	differentiated from normal IP packets in the MPLS ECMP case. Or in other 
>> 	words they will follow the same path with the PW OAM ones.
>>
>>     - The next 4 bits (4 to 7) MAY be used to provide flexible support for 
>> 	transport-specific treatments for any given AC type:
>>
>> 	 . Bit 4 (B) used to signal Backward Congestion Indication (BCI)
>> 	   This bit could be used to alleviate possible congestion situation 
>> 	   related to differences in speed between ACs located at the two sides 
>> 	   of an IP PW: e.g. Ethernet/ATM AC X --> FR AC Y. 	      
>>
>> 	 . Bit 5 (F) used to signal Forward Congestion Indication (FCI) 	
>> 	 . Bit 6 (D) used to indicate the Discard Priority (DP)
>>
>> 	If the transmitting PE does not support the processing of the above 
>>       flags, it MUST set them to 0. If the receiving PE does not support the 
>>
>>
>>  Balus et.al                                                    Page 4 
>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires January 2005
>>
>>       processing of the flags it MAY ignore them upon reception.
>> 	 . Bit 7 is reserved and must be set to 0.
>>
>>     - FRG field (bits 8,9) MAY be used to provide support for PW Fragmentation 
>> 	to address MTU mismatch. The usage of these bits is compliant with the 
>> 	procedure described in [FRAG]. Note that the usage of PW fragmentation 
>>       could be negotiated using the parameter id described in section 4 of 
>>       [FRAG]. Alternatively, fragmentation at IP Layer could be used - see 
>>       section 3 of [FRAG]. In the latter case the packet is fragmented at the 
>>       ingress PE and reassembled just at the IP Destination device - i.e. the 
>>       egress PE does not get involved. As such this option could be enabled by
>>       provisioning just at the ingress PE.
>>
>>     - Length field (bits 10 to 15) MAY be used (see [Martini L2CIRC] section 
>>       3.1) in conjunction with the padding of short IP PW payloads (i.e. 40 
>>       Bytes) when the link layer protocol on the related PSN links requires a 
>>       minimum frame length: i.e. minimum payload for Ethernet is 64 bytes. If 
>>       the total length of the IP payload plus the CW (4 bytes) plus the 2 
>>       labels (8 bytes) is less than 64 bytes then the Length field indicates 
>>       the total length of the L2 payload (i.e. IP payload+12 bytes). Otherwise 
>>       the length field must be set to zero. The egress PE will remove the 
>>       padding and it will restore the frame to its original size. 
>>       Alternatively, the Length field from the IP header could be used to 
>>       address this issue. In this case the padding will be removed just at the 
>>       IP destination. 
>>
>>     - The next 16 bits provide a sequence number that can be used to guarantee
>> 	ordered packet delivery. The processing of the sequence number field is 
>> 	OPTIONAL and a value of 0 is used to indicate an unsequenced packet. 
>>       This Sequence number SHOULD be compliant with the rules defined in 
>>       [Martini L2CIRC] see section 3.1.1 and 3.1.2. 
>>
>>  5. Support for PW OAM
>>
>>     [VCCV] defines a set of OAM tools (i.e. Ping, BFD) to be used for 
>>     any type of PW encapsulation. One of the methods proposed to identify 
>>     the associated OAM flows (see Section 4.1 of [VCCV]) suggests the use 
>>     of the following format:
>>
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |0 0 0 1| reserved = 0  |  PA=0 |      PPP DLL Proto Number     |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>                      Figure 2: VCCV OAM Encapsulation
>>
>>     The first nibble (0001) together with PPP DLL Protocol Number field is 
>>     used to identify the OAM flows. This will enable, for the IP PW, the 
>>     unrestricted use of OAM mechanisms common to other PW types.
>>
>>
>>  Balus et.al                                                     Page 5 
>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires January 2005
>>
>>  6. Support for non-IP payload
>>     
>>     As a general rule PE1 and PE2 will discard the incoming non-IP payloads 
>>     on ACs X and Y. Still there could be exceptions from the above rule: e.g. 
>>     if CE1 and CE2 are using IS-IS for routing protocol, the IP PW might be 
>>     required to transport this non-IP payload between PE1 and PE2. 
>>
>>     To achieve the above goal, it is proposed to extend the PWE3 Payload Type 
>>     Identifier defined in [PWE3-CW] as follows:   
>>     
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |0 0 0 1| reserved = 0  |  PA=X |          Payload Type         |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>       Figure 2: IP PW Encapsulation used non-IP payload exceptions
>>
>>     The value PA=0 is reserved for PW OAM messages (VCCV PING, BFD). Values 
>>     other than zero are used to identify user packets which are not IP packet. 
>>     For example,  PA=1 (ISO protocol) and the corresponding ISO NLPID code 
>>     points could be used to provide support for transporting IS-IS frames over 
>>     an IP PW:
>>       0                   1                   2                   3 
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>      |0 0 0 1|      rsvd.    | PA=1  |ISO NLPID=0x83 |0 0 0 0 0 0 0 0| 
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>
>>  7. Signaling of the IP PW
>>
>>     A 15 bit quantity containing a value is used as part of the PWiD and 
>>     Generalized Id FECs to identify the type of PWs - see [PWE3-CTRL] sections 
>>     5.1 and 5.2. To signal the IP PW we propose the usage of the value 0x000b 
>>     already assigned in [IANA PWE3]section 2 for IP Layer2 Transport.
>>
>>     The negotiation of the control word complies with the procedure described 
>>     in [PWE3-CTRL] section 5.4.2.
>>
>>     No new TLVs, Interface parameters are required for now.
>>
>>  8. Security Considerations
>>     To be completed later.
>>
>>  9. Changes from the previous version
>>     
>>     - Improved the Abstract and Introduction to clarify the goal of the draft
>>     - Switched section "Support for PW OAM" (now 5, previously 4) with "IP PW 
>>       Encapsulation" (now 4, previously 5).
>>     - Comments in section 4: on the usage of BE(fragmentation) and Lenght bits 
>>     - Changed the format in section 6 to allign to the newly proposed PTI 
>>
>>  Balus et.al                                                     Page 6 
>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires January 2005
>>
>>  10. Acknowledgements
>>
>>     The authors would like to thank David Allan, Hamid Ould-Brahim, for 
>>     their helpful discussions and feedbacks.
>>
>>  11. Intellectual Property Rights Notices.
>>
>>     This document is being submitted for use in IETF standards discussions.
>>
>>  12. References
>>
>>     [PWE3 Architecture] "PWE3 Architecture", draft-ietf-pwe3-arch-
>>     07.txt, IETF work in progress, March 2004
>>
>>     [ARP Mediation] Shah, Himanshu "ARP Mediation for IP Interworking of
>>     Layer 2 VPN", draft-shah-l2vpn-arp-mediation-03.txt, IETF work in
>>     progress, October 2003
>>
>>     [IPLS] Shah,Himanshu "IP-Only LAN Service", draft-ietf-l2vpn-ipls-01.txt,
>>     IETF work in progress, May 2004
>>
>>     [RFC3032] "MPLS Label Stack Encoding" IETF RFC 3032
>>
>>     [2547] Rosen, E. Rekhter, Y., "BGP/MPLS VPNs", IETF RFC 2547,
>>       March 1999
>>
>>     [VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit Connection
>>     Verification (VCCV)", draft-ietf-pwe3-vccv-02.txt, February 2004
>>     [RFC2427] RFC 2427, "Multiprotocol Interconnect over Frame Relay"
>>
>>     [RFC2684] RFC 2684, "Multiprotocol Encapsulation over ATM Adaptation
>>     Layer 5"
>>
>>     [Martini L2CIRC] Martini et.al. "Encapsulation Methods for Transport
>>     of Layer 2 Frames Over IP and MPLS Networks", draft-martini-
>>     l2circuit-encap-mpls-07.txt, IETF Work in Progress, June 2004
>>
>>     [Martini L2TRANS] Martini et.al. "Transport of Layer 2 Frames Over
>> 	MPLS", draft-martini-l2circuit-trans-mpls-14.txt, IETF Work in
>> 	Progress, June 2004
>>
>>     [FR PW] Kawa et.al. "Frame Relay over Pseudo-Wires", draft-ietf-
>> 	pwe3-frame-relay-02.txt, IETF Work in Progress, February 2004
>>
>>     [ATM PW] Martini et.al. "Encapsulation Methods for Transport of ATM
>> 	Over IP and MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt, IETF
>> 	Work in Progress, April 2004
>>
>>     [PWE3-CTRL] Martini et.al. "Pseudowire Setup and Maintenance using
>>       LDP", draft-ietf-pwe3-control-protocol-07.txt, IETF Work in
>>       Progress, June 2004
>>
>>  Balus et.al                                                     Page 7
>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires January 2005
>>
>>     [IANA PWE3] Martini, Townsley "IANA Allocations for pseudo Wire Edge
>>       to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-04.txt 
>> 	(work in progress), April 2004
>>    
>>     [IANA PPP] IANA Point-to-Point Protocol Field Assignments, June 28,2004 
>> 	http://www.iana.org/assignments/ppp-numbers
>>
>>     [RCF3032] RFC 3032 Rosen, et al., "MPLS Label Stack Encoding", January 
>>       2001
>>     
>>     [PWE3-CW] Bryant-McPherson, "PWE3 Control Word" 
>> 	draft-bryant-mcpherson-pwe3-cw-00.txt, July 2004
>>
>>  12. Authors' Addresses
>>
>>     Florin Balus
>>     Nortel Networks
>>     3500 Carling Ave.
>>     Ottawa, Ontario, CANADA
>>     e-mail: [email-masked]
>>
>>     Jeff Sugimoto
>>     Nortel Networks
>>     3500 Carling Ave.
>>     Ottawa, Ontario, CANADA
>>     e-mail: [email-masked]
>>
>>     Mike Loomis
>>     Nortel Networks
>>     Billerica, MA
>>
>>     Himanshu Shah 
>>     35 Nagog Park, 
>>     Acton, MA 01720 
>>     Email: [email-masked] 
>>
>>     Mircea Pisica
>>     Infonet Services Corporation
>>     Brussells, Belgium
>>
>>     Mustapha Aissaoui
>>     Alcatel
>>     600 March Rd
>>     Kanata, ON, Canada. K2K 2E6
>>     Email: [email-masked] 
>>
>>     Full copyright statement
>>     Copyright (C) The Internet Society (2004). 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.
>>
>>
>>  Balus et.al                                                     Page 8 
>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires January 2005
>>
>>     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.
>>
>>     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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  Balus et.al                                                     Page 9