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

["Florin Balus" <[e-mail]>]

Luca,

So from what you are saying below in your opinion PW/MPLS is not going
to be the service interface in the CE router? In other words for L2
Services there will always be Ethernet (or other <mix of> native) ACs at
both sides of the Virtual Circuit. I appreciate your insight. I am also
interested to hear back from Service Providers (and the PWE3 WG) in
general one more time though... 

Myself I see values to have a common service layer end to end, instead
of translating encapsulations, OAM and other native procedures (e.g.
ARP) between different types of ACs or even AC and PW uplink. Also we
should have the option of building a common L2 path for multiple related
protocols (IP/IS-IS) instead of dictating one VC per protocol/having to
worry about making sure the PW paths/faults are correlated. 

On the other hand, if we are sure PW/MPLS architecture is not the right
way of getting there I am opened to look to alternatives. 

Regards,
Florin 

>-----Original Message-----
>From: Luca Martini [mailto:[e-mail]]
>Sent: Monday, February 20, 2006 11:26 AM
>To: Balus, Florin [CAR:6955:EXCH]
>Cc: Sasha Vainshtein; Busschbach, Peter B (Peter); pwe3 pwe3;
>Danny McPherson
>Subject: Re: [PWE3] Generic PW - Is there a need?
>
>
>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:
>> 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:[e-mail]]
>>> 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>
>>>
>>>     
>>> 
>---------------------------------------------------------------------
>>> ---
>>>
>>>
>>>
>>>  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: [e-mail]
>>>
>>>     Jeff Sugimoto
>>>     Nortel Networks
>>>     3500 Carling Ave.
>>>     Ottawa, Ontario, CANADA
>>>     e-mail: [e-mail]
>>>
>>>     Mike Loomis
>>>     Nortel Networks
>>>     Billerica, MA
>>>
>>>     Himanshu Shah 
>>>     35 Nagog Park, 
>>>     Acton, MA 01720 
>>>     Email: [e-mail]
>>>
>>>     Mircea Pisica
>>>     Infonet Services Corporation
>>>     Brussells, Belgium
>>>
>>>     Mustapha Aissaoui
>>>     Alcatel
>>>     600 March Rd
>>>     Kanata, ON, Canada. K2K 2E6
>>>     Email: [e-mail]
>>>
>>>     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
>
>

_______________________________________________
pwe3 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pwe3