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

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 31 Jan 2006 18:24:29 +0200

Stewart, Danny and all,
Are we possibly speaking about something like "multiprotocol interconnect
over PW" similar to multiprotocol interconnect over FR (RFC 2427/STD 55) or
multiprotocol interconnect over AAL5 (RFC 2684)? 
 
Regards,
                    Sasha

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Tuesday, January 31, 2006 4:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] Generic PW - Is there a need?

[email-masked] <mailto:[email-masked]>  wrote:

Danny,

It is not entirely clear to me what the proposal you are making is or

the motivation behind it.

Are you stating that to support IPLS, transport of MPLS PWs over a PW

etc. that a new control word format/encapsulation is required and this

document will specify such a control word format?  If so, what is

deficient/missing in the current control word formats?

You need a standard method to multiplex a number of protocols over the 
PW. It's not always the case that the only protocol that needs to be
carried is IP. You might want to carry IP + ISIS, or IP + MPLS etc.
We could do this by defining a canonical data-link type, or by
adding a PID to the PW. How we do it is a WG decision.

Or is it to just essentially combine several PW types into a single

document rather than a document per PW type?

No, we think that there is a need to carry multiple types over the same PW.

- Stewart

Or am I completely missing the point?

Thanks

Ben

[email-masked] <mailto:[email-masked]>
<mailto:[email-masked]> <mailto:[email-masked]> wrote:

Folks,

We would like to start a discussion on whether the PWE3 WG

should work on the definition of a generic packet PW.

The driver for this work is threefold:

1) The need for a PW to support the IPLS work in the L2VPN WG

2) The need to provide an MPLS PW to satisfy the same need as

the IP PW proposed in the L2TPext WG

3) The need to provide PW to transport MPLS PWs

This type of PW is generally needed where it is required to

interconnect ACs with two (actually or potentially) disparate Layer 2

protocols. 

Generally one would use a Layer 3 service to provide this,

but the use of a Layer 2 service allows greater decoupling

between the client and transport networks.

The types of packets that need to be carried over a generic

packet PW are know to be (are there others?):

IPv4

IPv6

IS-IS

MPLS

Compressed IP

In all cases the payload would be carried over a PW with a CW

to allow ECMP suppression and the discrimination of different

packet types multiplexied over the PW, for example IPv4

packets and IS-IS protocol packets. Because a CW was used the

EoS bit would need to be set in the transport label stack, as

well as in the client label stack.

A generic PW would be supported by its own OAM mechanism

(VCCV) which would be different from any client OAM mechanism.

One application for the service would be a SP transit domain

in which it was desired that there was no interaction between

the client and transport network protocols (e.g., MPLS LSP

transport services w/no LDP interaction between the transport and

client networks). 

The work within PWE3 would be a short encapsulation

specification and applicability statement.

Where the generic packet PW payload was MPLS the PW would be

transparent to the MPLS client layer and not an extension of

the MPLS heirachy. This would need to be made clear in the

applicability statement. 

Do folks here have comments either way on the utility,

application and/or requirement for this (i.e., if you're in

favor or against please make it known to the list)?

Thanks!

-danny & Stewart

_______________________________________________

pwe3 mailing list

[email-masked] <mailto:[email-masked]> 

https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3> 

_______________________________________________

pwe3 mailing list

[email-masked] <mailto:[email-masked]> 

https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3> 

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 31 Jan 2006 12:25:03 -0500

Sasha,

Yes, I was about to send out an email with the same conclusion.  It 
should be relatively straightforward to adapt one of these two 
(probably 2684, given its header word alignment vs. header byte 
alignment in 2427) for this purpose.  I've always been of the opinion 
that we should have included a PID in the MPLS header way back when, 
but that was the minority opinion at the time.

Cheers,
Andy

-------------

At 1/31/2006 06:24 PM +0200, Sasha Vainshtein wrote:
>Stewart, Danny and all,
>Are we possibly speaking about something like "multiprotocol 
>interconnect over PW" similar to multiprotocol interconnect over FR 
>(RFC 2427/STD 55) or multiprotocol interconnect over AAL5 (RFC 2684)?
>
>Regards,
>                     Sasha
>
>
>
>
><mailto:[email-masked]>[email-masked] wrote:
>>
>>Danny,
>>
>>

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Tue, 31 Jan 2006 13:06:31 -0500

All,
Andy and I made a proposal in the Vienna meeting that extended the original
PID proposed by Dave. The PID aligns with RFC 2427 in terms of structure but
this is open for debate. Clearly, we do not want to support all different
encoding types and combinations which are listed here, but at least a
meaningful subset based on the requirements for this work item.
 
See attached.
 
Mustapha.

      Network Working Group                              Mustapha Aissaoui 
      Internet Draft                                         Matthew Bocci 
      Expiration Date: April 2004                          David Watkinson 
                                                                   Alcatel 
                                                                           
                                                           Andrew G. Malis 
                                                                   Tellabs 
                                                                           
                                                              October 2003 

                            Extended MPLS/PW PID 
                     draft-aissaoui-extended-pid-01.txt 

   Status of this Memo 
      
     This document is an Internet-Draft and is in full conformance with 
     all provisions of section 10 of RFC 2026. 
      
     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>
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> http://www.ietf.org/shadow.html. 

  Abstract 
      
     This draft proposes the extension of the proposed MPLS/PW PID to 
     include the identification of user protocols and multiple control 
     plane protocols carried in a PW or MPLS LSP. 
   
  Table of Contents 
      
     Status of this Memo.............................................1 
     Abstract........................................................1 
     Table of Contents...............................................1 
     1 Conventions used in this document.............................2 
     2 Introduction..................................................2 

  Aissaoui, et al.          Expires April 2004
[Page 1]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 
   
     3 Extended MPLS/PW PID..........................................3 
      3.1 Structure of the Extended MPLS/PW PID......................4 
      3.2 User-Plane Protocol Identification Details.................4 
     4 Signaling of the extended MPLS/PW PID.........................5 
     5 Security Considerations.......................................5 
     6 Intellectual Property Disclaimer..............................6 
     7 Appendix A: Application of the Extended MPLS/PW PID to Layer 2 
     interworking....................................................6 
      7.1 Interworking Considerations................................8 
      7.2 Application of the Extended MPLS/PW PID to MPLS/PW OAM.....9 
     8 References....................................................9 
     9 Acknowledgments..............................................10 
     10 Authors' Addresses..........................................10 
     11 Full Copyright Statement....................................11 

  1    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. 

  2    Introduction 
      
     There has been much discussion in the PWE3 and MPLS working group 
     mailing lists about the concept of MPLS or PW protocol identifier 
     (PID). A number of applications for the MPLS/PW PID have been 
     identified: 
      
     a. The first one has to do with the IP aliasing issue [1]. In 
        networks where load balancing schemes such as ECMP are used, 
        the first nibble immediately following the bottom of the label 
        stack may infer a IPv4 or IPv6 if its value is 4 or 6. Some 
        ECMP implementations include this nibble in the hashing 
        mechanism and may attempt to process further information beyond 
        this nibble if the packet is mistaken for an IP packet. It is 
        therefore required that non-IP payloads not to infer these two 
        values. In the specific case of PWE3 applications, this issue 
        is addressed by forcing the first nibble of the generic control 
        word or of the preferred control word to a value of zero [1]. 
        However, the SONET PW control word [2] does not comply with 
        this requirement. The SONET encapsulation addresses this issue 
        by preceding the SONET control word with a MPLS/PW PID to 
        disambiguate its payload from an IP packet. 
      
     b. The second one has to do with the ability to identify in PE, 
        MPLS or PW OAM messages, such as Y.1711 [3], LSP-Ping [4], or 
        VCCV [5]. Y.1711 messages are MPLS control packets, while LSP-
        Ping and VCCV are IP control packets. All can be inserted in a 
        non-IP LSP in the case of PWE3 applications. A PE can make use 
    
  Aissaoui, et al.          Expires April 2004
[Page 2]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 
   
        of the MPLS/PW PID to indicate to the remote PE that the 
        payload is an OAM packet without the need for a special label 
        value. 
      
     c. The third one is about making sure that a MPLS or a PW OAM 
        packet follows exactly the same path as the user traffic if 
        ECMP or similar load sharing mechanisms are used in the 
        network. This is fairly important since the whole idea of OAM 
        packet is to check the sanity and to troubleshoot the path user 
        packets follow through the network. The currently proposed MPLS 
        or PW OAM messages rely on a reserved label value to carry 
        these messages. For example, LSP-Ping makes use of the router 
        alert label value while Y.1711 OAM makes use of the OAM alert 
        label value. In both cases, another label is pushed into the 
        stack and thus the hashing algorithm of some ECMP 
        implementations may cause the OAM packet to follow a different 
        path from the user packet. If a MPLS/PW PID is used instead of 
        a special label value, this problem can be resolved. A proposal 
        for MPLS/PW PID to address this issue was made in draft-allan-
        mpls-pid-00.txt [6]. 
       
     This draft proposes to extend the use of the MPLS/PW PID to 
     identify user plane protocols carried in the LSP/PW payload. The 
     main application is interworking of different link layers over a 
     MPLS network, where each data link layer is terminated locally in 
     a PE. The MPLS/PW PID allows the use of a single multiprotocol PW 
     between any two user sites. The issues that are resolved by this 
     method are explained in Appendix A. 
      
     Appendix A also discusses the use the MPLS/PW PID to identify 
     different types of OAM messages in a PW in such a way to address 
     issues (b) and (c) above. 

  3    Extended MPLS/PW PID 
      
     The proposed structure of the MPLS/PW PID is compatible with the 
     MPLS payload type identifier in the PWE3 architecture document 
     [1]. Furthermore, it is compatible with RFC 2684 (Multiprotocol 
     over ATM), RFC 2427 (Multiprotocol over Frame Relay), and RFC 2878 
     (Bridging over PPP). 
      
     Support for this format of the PID is only needed when there are 
     multiple protocol types being transmitted over the same PW.  It is 
     unnecessary when there is a single protocol even if this single 
     protocol multiplexes other protocols. 
      
     When only partial support is provided for this PID, the handling 
     of multiple alternatives referred to in section 3.2 should be 
     examined. 

    
  Aissaoui, et al.          Expires April 2004
[Page 3]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 
   
  3.1      Structure of the Extended MPLS/PW PID 
      
     The structure of the proposed MPLS/PW PID is shown in Figure 1: 
      
      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  |            Protocol ID        | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
     Rsvd.   = reserved for future use (== 0) 
     PA      = protocol authority for the user plane or the control   
               plane protocol ID 
                             0       = PPP DLL. Reserved for MPLS/PW     
                                       control protocol identification. 
                             1       = ISO NLPID (other than 0x80) 
                             2       = IP protocol number 
                             3       = Ethertype 
                             4       = SNAP (ISO NLPID=0x80, e.g., IEEE   
                                       802.1 MAC type) 
                             5-15    = reserved 
     Protocol ID   = Protocol ID following the format defined by the 
     protocol authority identified in PA. 
      
                  Figure 1: Extended MPLS/PW PID Structure 
 
  3.2      User-Plane Protocol Identification Details 
      
     The user plane encapsulation follows the procedures in the 
     NLPID/SNAP encapsulation in RFC 2427 (Multiprotocol over Frame 
     Relay). Where there are multiple alternatives to identify a 
     specific protocol, the use of the representation with the lowest 
     PA possible is required. For example, an IP datagram is 
     represented using PA=1 and an ISO NLPID=0xCC. 
      
     PA=1: ISO NLPID value other than 0x80 (32 bits) 
      
      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     |0 0 0 0 0 0 0 0| 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
     The following ISO NLPID values are supported using this 
     configuration: 
     0x81    ISO CLNP 
     0x82    ISO ESIS 
     0x83    ISO ISIS 
     0xCC    IP 
     0xCF    PPP 
      
     PA=2, IP protocol number (32 bits) 
    
  Aissaoui, et al.          Expires April 2004
[Page 4]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 

      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=2  |         IP Protocol ID        | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
     PA=3: Ethertypes (32 bits) 
      
      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=3  |           Ethertype           | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
     PA=4: SNAP protocols such as 802.1 MAC types and private protocols 
     (64 bits) 
      
      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=4  | NLPID=0x80    |      OUI      | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |     OUI (cont'd)              |            PID                | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
     IEEE 802.1 bridged protocols are carried in the MPLS or PW payload 
     using PA=4 and the 802.1 organization code of 0x00-80-C2 in the 
     OUI field in the SNAP header. The following are the PID field 
     values used to identify the different bridged protocols: 
      
     with preserved FCS   w/o preserved FCS    Media 
        ------------------   -----------------    -------------- 
        0x00-01              0x00-07              802.3/Ethernet 
        0x00-02              0x00-08              802.4 
        0x00-03              0x00-09              802.5 
        0x00-04              0x00-0A              FDDI 
                             0x00-0B              802.6 
                             0x00-0D              Fragments 
                             0x00-0E              BPDUs as defined by 
                                                  802.1(d) or 802.1(g) 
                             0x00-0F              Source Routing BPDUs 

  4    Signaling of the extended MPLS/PW PID 
      
     This section is for further study. 

  5    Security Considerations 
      
     This draft does not introduce any new security considerations to 
     MPLS.  
    
  Aissaoui, et al.          Expires April 2004
[Page 5]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 

  6    Intellectual Property Disclaimer 
      
     This document is being submitted for use in IETF standards 
     discussions.  

  7    Appendix A: Application of the Extended MPLS/PW PID to Layer 2 
  interworking 
      
     Note: this appendix is not intended to be part of the 
     specification of the MPLS/PW PID. It is only provided to highlight 
     an application of the MPLS/PW PID. The content of this appendix 
     will be moved to a separate draft in the next revision of this 
     draft. 
      
     Figure 2 shows an example of interworking of different link layers 
     over MPLS.  
                                       
             |CE1|--FR--|PE1|----MPLS----|PE2|--Ethernet--|CE2| 
                                    \       / 
                                     \     / 
                                      \   / 
                                      |PE3| 
                                        | 
                                       ATM 
                                        | 
                                      |CE3| 
                                        
          Figure 2: Interworking of different link layers over MPLS 
                                       
     Each AC can carry multiple higher layer protocols. This type of 
     interworking can be achieved in three different ways. Each method 
     is valid and has its own advantages and disadvantages. 
      
          1. Extend one link layer to the remote PE:  
             for example, the ATM link layer between CE3 and PE3 in 
             Figure 2 can be extended to PE2 using the PWE3 ATM-MPLS 
             encapsulations [9]. In PE2, the ATM PW is terminated and 
             the corresponding ATM AAL5 payload is reconstructed. Then 
             ATM and Ethernet link layers are interworked and the 
             corresponding PID fields are translated. The same thing 
             can be done for the FR link between CE1 and PE1 using a FR 
             PW towards PE2. Note that extending the Ethernet link 
             layer makes only sense if it is done all the way to the 
             ATM and FR CEs using a bridged encapsulation over the FR 
             and ATM links, and Ethernet PWs between the PEs. 
             Otherwise, PE1 and PE3 will need to insert a (fake) MAC 
             address for the FR and ATM interfaces on CE1 and CE3 in 
             order to communicate with CE2. 

  Aissaoui, et al.          Expires April 2004
[Page 6]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 
   
             This method has the advantage of reusing existing PW 
             encapsulations specified in the PWE3 working group. It 
             also simplifies the interworking with MPLS since it does 
             not require the identification of the higher layer 
             protocols carried in an AC.  
             However, it makes the assumption that a PE will need to 
             terminate multiple L2 over MPLS encapsulations even if it 
             does not support those L2 interface types. For example, 
             PE2 might only have Ethernet and MPLS interfaces and not 
             ATM interfaces. In order to use this method, it will need 
             to terminate and process ATM PWs as specified in [9]. 
           
          2. Set up multiple pseudo-wires for each AC:  
             This method is described in [8]. In this case, each link 
             layer is terminated locally in a PE which inspects each 
             packet's PID to select the PW dedicated to each protocol 
             type. Therefore, multiple PWs need to be set up for each 
             AC. In the case where IP packets are routed over the AC 
             while all other protocols are bridged over the AC, this 
             method reduces to the set up of 2 parallel pseudo-wires 
             for each AC: an IP PW and an Ethernet PW. 
              
             This method has the advantage of using the current PW 
             model of inferring the protocol carried in the PW from the 
             label value. In other words, each PW carries only one 
             protocol type. 
              
             The disadvantage of this method is that it requires the 
             association of multiple PWs to a single AC. This is a 
             change to the current forwarding behavior of a PW. That 
             is, the traffic received on a AC is forwarded over a PW 
             based on the attachment circuit and the PID in the link 
             layer encapsulation. 
              
             There are also cases where one wants to avoid splitting 
             the path of the carried protocols. For example, the CE in 
             Figure 2 could be a device of another service provider who 
             runs IS-IS as its IGP while the rest of the traffic is IP. 
             In normal operation, a failure of the datapath is detected 
             by the IS-IS routing plane since routing packets follow 
             the same path as user packets. If the IP PW fails while 
             the IS-IS PW is still up, there is no way to let the IS-IS 
             routing know about the failure except by tearing down the 
             IS-IS PW. The tearing down of a group of PWs when one of 
             them fails is not desirable for other types of user 
             protocols who do not have such kind of dependency. 
           
          3. Set up a multiprotocol PW and translate the PID: 
             In this method, each link layer is terminated locally in a 
             PE which inspects each received packet in an AC and 
             translates the link layer PID into a PW PID. The PW PID 
             has the format proposed in Section 3 of this document. 

  Aissaoui, et al.          Expires April 2004
[Page 7]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 
   
             This method allows the creation of a single multiprotocol 
             PW to carry all protocols in an AC.  
              
             Consider the example of the traffic between CE1 and CE2 in 
             Figure 2. The CE device could belong to a service provider 
             running IS-IS as its IGP. The interworking here is between 
             an Ethernet interface and an rfc2427 routed FR DLCI with 
             IP and ISIS routing traffic.  The ISIS routing traffic can 
             be carried over the same PW as the IP traffic by using an 
             extended PID with PA=1 and NLPID=0x83.  The NLPID is 
             interworked to 802.3 LLC on the Ethernet side of the PW by 
             adding the appropriate LLC of FEFE03 using the same 
             mapping as defined in FRF 8.1 [10]. 
   
             This method has the advantage of requiring a single PW to 
             carry multiple user protocols over MPLS. It maintains the 
             same path for both user and control plane protocols of the 
             customer of the network. Finally, it provides a consistent 
             operation with existing FR-ATM service interworking 
             deployments. 
              
             The disadvantage of this method is that the PE needs to 
             inspect the received traffic on a PW packet by packet in 
             order to translate the PID. Note however that the PW 
             forwarding paradigm is not changed. Forwarding is still 
             based on the label and the attachment circuit for each 
             direction respectively. PID translation can be viewed as 
             part of payload manipulation. 

  7.1      Interworking Considerations 
      
     Regardless of which of the 3 above methods is used to perform 
     interworking of different link layers over MPLS, there are two 
     orthogonal issues to resolve: 
      
     a. Identification of multiple higher-layer protocols:  
        When a CE multiplexes multiple protocols in a single AC, it 
        indicates the protocol type in a protocol identifier (PID) 
        field in the link layer encapsulation. For example, RFC 2684 
        specifies the format for this field for an ATM/AAL5 link layer. 
        A PE examines the PID of each packet received in a AC to either 
        select the PW dedicated to this protocol (method 2) or to 
        translate the link layer PID into a PW PID(method 3). In the 
        case of method 1, the PE performs a translation of the PID 
        between two link layers, for instance ATM/AAL5 and Ethernet in 
        the example above. 
      
     b. L3 protocol dependency on the type of link layer:  
        Consider again the example of IS-IS traffic and IP traffic 
        carried between CE1 and CE2 in Figure 2. The operation of ISIS 
    
  Aissaoui, et al.          Expires April 2004
[Page 8]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 
   
        over a PW can treat the link as a broadcast link or a point-to-
        point link.  When it is point-to-point (i.e., only one CE 
        device on the Ethernet end), the procedures in draft-ietf-isis-
        igp-p2p-over-lan [11] will apply.  When it is broadcast, there 
        can be multiple CE routers on the Ethernet AC.  The preferred 
        choice in this particular case is to change the FR AC to 
        bridged encapsulation and use an Ethernet PW.  This will allow 
        the FR attached CE (CE2) to properly participate when presented 
        with packets with the three multicast MAC addresses AllISs, 
        AllL1ISs, and AllL2ISs.  If the FR AC is not or cannot be 
        changed to bridged encapsulation, the Ethernet attached PE will 
        need to assume that all ISIS packets received across the PW 
        should be prepended with the AllISs destination MAC or dig into 
        the packet to determine the MAC to use based on the packet 
        type.  The procedures for ARP Mediation [12] need to be applied 
        to determine a source MAC address. 

  7.2      Application of the Extended MPLS/PW PID to MPLS/PW OAM 
      
     In order to address issues (b) and (c) in Section 2, the MPLS/PW 
     PID can be used to identify an MPLS/PW OAM message carried in a 
     PW. This is an alternative to the router alert label value in LSP 
     Ping/VCCV and to the OAM alert label value in Y.1711 MPLS OAM.  
      
     An IP control packet (LSP Ping/VCCV) inserted in a PW is 
     identified by including the MPLS/PW PID just below the bottom of 
     the MPLS label stack as explained in [5]. The PA field is set to 0 
     to indicate a MPLS/PW control plane protocol. The PID field is a 
     PPP DLL and is set to the value indicating an IPv4 or IPv6 packet. 
      
     Similarly, a Y.1711 OAM message is identified through a PA=0 and a 
     specific value of the PPP DLL to be assigned by IANA. 

  8    References 
      
     [1]  Bryant, S., "The PWE3 Architecture", draft-ietf-pwe3-arch-
          06.txt, October 2003. 
      
     [2]  Malis, A., et al.,"SONET/SDH Circuit Emulation over Packet 
          (CEP)", draft-ietf-pwe3-sonet-01.txt, January 2003.  
      
     [3]  "OAM Mechanisms for MPLS Networks", ITU-T Recommendation 
          Y.1711, November 2002. 
      
     [4]  Kompella, K., et al., "Detecting MPLS Data Plane Liveness", 
          draft-ietf-mpls-lsp-ping-03.txt, June 2003. 

  Aissaoui, et al.          Expires April 2004
[Page 9]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 
   
     [5]  Nadeau, T., et al., "Pseudo Wire (PW) Virtual Circuit 
          Connection Verification (VCCV), draft-ietf-pwe3-vccv-00.txt, 
          July 2003. 
      
     [6]  Allan, D., "MPLS and IP PW Payload ID", draft-allan-mpls-pid-
          00.txt, April 2003. 
      
     [7]  Moreels, J., et al., "Multi-protocol encapsulation over 
          MPLS", draft-moreels-multiproto-mpls-00.txt, October 2002. 
      
     [8]  Sajassi, A., et al., "L2VPN Interworking", draft-sajassi-
          l2vpn-interworking-01.txt, March 2003. 
      
     [9]  Martini, L., et al.," Encapsulation Methods for Transport of 
          ATM Cells/Frame Over IP and MPLS Networks", draft-ietf-pwe3-
          atm-encap-03.txt, October 2003. 
      
     [10] Frame Relay Forum, "FRF 8.1 - Frame Relay / ATM PVC Service 
          Interworking Implementation Agreement", February 2000. 
      
     [11] Shen, N., et al., "Point-to-point operation over LAN in link-
          state routing protocols", draft-ietf-isis-igp-p2p-over-lan-
          03.txt, September 2003. 
      
     [12] Shah, H., et al., "ARP Mediation for IP interworking of Layer 
          2 VPN", draft-shah-ppvpn-arp-mediation-02.txt, July 2003. 

  9    Acknowledgments 
      
     The authors like to acknowledge the contribution to this work by 
     Jeremy de Clercq, John Fischer, Johan Moreels, Stefaan De Cnodder, 
     Dimitri Papadimitriu, Dave Allan, and Stewart Bryant. Some of the 
     drivers and applications for this draft were initially presented 
     in draft-moreels-multiproto-mpls [7]. The idea of a Protocol 
     Authority (PA) field was originally proposed in draft-allan-mpls-
     pid [6].  

  10     Authors' Addresses 
      
     Mustapha Aissaoui 
     Alcatel 
     600 March Rd 
     Kanata, ON, Canada. K2K 2E6 
     Email:  <mailto:[email-masked]>
[email-masked]  
      
     Matthew Bocci 
     Alcatel 
     Voyager Place, Shoppenhangers Rd 
     Maidenhead, Berks, UK SL6 2PJ 
     Email:  <mailto:[email-masked]>
[email-masked] 

  Aissaoui, et al.          Expires April 2004
[Page 10]  
   
  Internet Draft    draft-aissaoui-extended-pid-01.txt               October
2003 
   
     David Watkinson 
     Alcatel 
     600 March Rd 
     Kanata, ON, Canada. K2K 2E6 
     Email:  <mailto:[email-masked]>
[email-masked] 
      
     Andrew G. Malis 
     Tellabs 
     2730 Orchard Parkway 
     San Jose, CA 95134 
     phone:+1 408-383-7223 
     email:[email-masked] 
      
  11     Full Copyright Statement 
      
     "Copyright (C) The Internet Society (2003). Except as set forth 
     below, authors retain all their rights. 
      
     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 rights in submissions defined in the IETF 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 is provided on 
     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 
     REPRESENTS (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. 

 

    
  Aissaoui, et al.          Expires April 2004
[Page 11]