Subject: FW: draft-ietf-pwe3-control-protocol-08.txt Generalized FE C clarific ation

From: "Agiwal, Manoj (Manoj)" <[email-masked]>
Date: Thu, 23 Sep 2004 12:53:49 +0530

Thanks Luca ,

   draft-ietf-pwe3-atm-encap-06.txt explains N to 1 cell mode ( Single and
Multiple Connection deployment models )
   as REQUIRED .

   Is control plane support for N to 1 cell mode of encapsulation, there in
IETF agenda .

Regards ,
Manoj

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Thursday, September 23, 2004 2:35 AM
To: Agiwal, Manoj (Manoj)
Cc: [email-masked]'
Subject: Re: [PWE3] draft-ietf-pwe3-control-protocol-08.txt Generalized
FEC clarific ation

Agiwal, Manoj (Manoj) wrote:

>Hi ,
>        This is w.r.t to ATM pseudowires , I wanted some clarification as
to
>usage of Generalized FEC TLV .
>
>      1.  Does the current draft-ietf-pwe3-control-protocol-08.txt takes
>care of support n to 1 cell mode of encapsulation .
>
>  
>
only n=1 mode is defined. There is no definition for more then one ATM 
VC into one PW.

>       2. Generalised FEC element has SAI and DAI  , Can SAI and DAI
>identify Atachment circuit at the end points .
>
>  
>
>       3.  In case multiple circuits are getting mapped to a pseudowire  ,
>Is it possible that label mapping message which 
>           carries the psedowire label , can be same for different pairs of
>< SAI and DAI > which needs to be mapped to
>           a pseudowire and therby supporting n to 1 cell mode of
>encapsulation .
>
>  
>
no.

>      4.  In case a particular Attachment Circuit goes inactive can the
>Status message be used along with Generalised FEC to 
>           inform the remote end which Attachment Circuit has gone down.
>
>
>  
>
Yes , the document clearly indicates this.

Luca

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

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 23 Sep 2004 03:59:35 -0400

> Sent: Wednesday, September 22, 2004 5:05 PM
> >        This is w.r.t to ATM pseudowires , I wanted some 
> clarification as to
> >      1.  Does the current 
> draft-ietf-pwe3-control-protocol-08.txt takes

Hi Luca,

I am not sure I understand this. I don't see anything in the existing IETF drafts that limits the use of n:1 cell mode encapsulation to a single VP.

The MPLS Forum is working on an "ATM-MPLS Control Plane Interworking" Implementation Agreement that, among other things, defines the concept of Virtual Trunks. A Virtual Trunk is a bundle of VPs that is encapsulated in a single PW. 

Currently, a Virtual Trunk setup procedure has not yet been defined, but there is no reason to believe that the PW Control Protocol with Generalized FEC could not be used.

Peter

---

From: "Agiwal, Manoj (Manoj)" <[email-masked]>
Date: Thu, 23 Sep 2004 12:53:49 +0530

<[email-masked]>
	
Content-Type: text/plain

Thanks Luca ,

Regards ,
Manoj

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Thursday, September 23, 2004 2:35 AM
To: Agiwal, Manoj (Manoj)
Cc: [email-masked]'
Subject: Re: [PWE3] draft-ietf-pwe3-control-protocol-08.txt Generalized
FEC clarific ation

to

no.

Luca

>Manoj

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

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 23 Sep 2004 03:59:35 -0400

<[email-masked]>
	
Content-Type: text/plain

Hi Luca,

I am not sure I understand this. I don't see anything in the existing IETF
drafts that limits the use of n:1 cell mode encapsulation to a single VP.

The MPLS Forum is working on an "ATM-MPLS Control Plane Interworking"
Implementation Agreement that, among other things, defines the concept of
Virtual Trunks. A Virtual Trunk is a bundle of VPs that is encapsulated in a
single PW. 

Currently, a Virtual Trunk setup procedure has not yet been defined, but
there is no reason to believe that the PW Control Protocol with Generalized
FEC could not be used.

Peter

> Yes , the document clearly indicates this.

------_=_NextPart_000_01C4A14D.A0A3BAD8
Content-Type: text/plain;
	name="enhancement3.txt"
Content-Disposition: attachment;
	filename="enhancement3.txt"
Content-Transfer-Encoding: quoted-printable

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

   changes to=20

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

Document Title:
               Pseudowire Setup and Maintenance using LDP

Document Name:
                draft-ietf-pwe3-control-protocol-08.txt

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

1. Signaling of PW ATM Service Status :

1.1 ATM N to 1 PWE3 Pre-processing:
=20
   Some ATM N to 1 PWE3 implementations might need pre-processing=20
   functions at the PE (refer to PWE3 reference model [12]). This=20
   includes translation of locally significant VPI/VCI . The=20
   pre-preprocessing operation at PE should allocate VPI/VCI at PE
   which must be unique for each ATM attachment circuit carried over
   the PWE3. ATM attachment circuits coming from different interfaces =
could
   have the same VPI/VCI which needs to map to a unique VPI/VCI per=20
   PWE3 at the PE.

1.2 PW ATM Service Status TLV:

   PWE3 supports ATM N To 1 Cell mode. The encapsulation allows=20
   multiple VCCs/VPCs to be carried within a single pseudo wire.

   The PE devices use an LDP TLV to indicate status for each ATM
   connection to their remote peers.

   The format of the PW ATM Service Status TLV is:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|PW Service Status (0x096D) |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RES |M|   VPI                 |            VCI                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Status Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   [ note: TLV type 0x096D as defined in [13] pending IANA allocation ]
  =20
   3 bit RES field is reserved. Padded to zero.
=20
   The M bit can be set to report multiple VPI VCI.

   An example format of PW ATM Serivce Status TLV when reporting=20
   multiple VPI/VCI is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|PW Service Status (0x096D) |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RES |1|   VPI1                |            VCI1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RES |1|   VPI2                |            VCI2               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RES |0|   VPI3                |            VCI3               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Status Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the status code is a 4 octet bit field is specified in the PW
   IANA Allocations document [13].

   The Status TLV is transported to the remote PW peer via the LDP
   notification message. The general format of the Notification Message
   is:

    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|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status (TLV)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  PW ATM Service Status TLV                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 PWId FEC or Generalized ID FEC                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Status TLV status code is set to 0x00000030 "PW ATM Service =
status",
   to indicate that PW status follows. Since this notification does not
   refer to any particular message the Message Id, and Message Type
   fields are set to 0.  [ note: Status Code 0x00000030 as defined in
   [13] pending IANA allocation ]=20

   The PW FEC TLV SHOULD not include the interface parameters as they
   are ignored in the context of this message.

   Note that if the PW ATM Service Status TLV is not supported, by the=20
   remote peer, it will automatically be ignored, since the LDP ignore =
bit=20
   is set.

   It is strongly RECOMMENDED that the PW ATM service status signaling=20
   be fully implemented for implementions which intend to support ATM
   N to 1 cell mode.=20

   The VPI/VCI fields in the PW ATM service status TLV carries the=20
   unique VPI/VCI which is allocated by the pre-processing function at =
the PE.=20

1.3 Procedures for sending Status Message for ATM Attachment circuits:

1.3.1 These procedures are applicable for the following status codes:

    0x00000020    ATM VC status ack=20
    0x00000040    ATM VC active
    =20

1.3.2 States for ATM Attachment Circiut:
    a. INVALID
    b. STATUS-SENT
    c. STATUS-RCV=20
    c. STATUS-ACK=20

1.3.3 Events at ATM Attachment Circiut:
    1. creation of Attachment circuit
    2. snd status code "ATM VC active"
    3. rcv status code "ATM VC status ack"=20
    3. rcv status code "ATM VC active"=20

1.3.4 Procedures:

     Figure 3 shows the two ends of an ATM attachment cricuit AC1.
     1/33 and 1/34 are the sample VPI/VCI's created for AC1. Same =
VPI/VCI
     can be allocated at both the ends AC1.

                              =20
                         |<----- Pseudo Wire ---->|
                         |                        |
                         |  |<-- PSN Tunnel -->|  |
            ATM Service  V  V                  V  V  ATM Service
                 |     +----+                  +----+     |
       +----+    |     | =
PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| PE2|     |  =
  +----+
       |    |----------|............PW1.............|----------|    |
       | CE1|    |     |    |                  |    |     |    |CE2 |
       |    |----------|............PW2.............|----------|    |
       +----+    |     |    =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|    |     |    =
+----+
            ^          +----+                  +----+     |    ^
            |      Provider Edge 1         Provider Edge 2     |
            |                                                  |
            |<-------------- Emulated Service ---------------->|
       Customer                                                Customer
       Edge 1                                                  Edge 2

           AC1(preceding)                            AC1(succeding)
           |                                                  |
           |TX                                      RX( 1/33) |
           | -----------------------------------------------> |
           |                                                  |
           |RX(1/34)                                        TX|
           | <----------------------------------------------- |
           |                                                  |
           |                                                  |
           |                                                  |

     1. Creation of an ATM attachment circuit AC1 SHOULD initialize=20
        the state of AC1 to "INVALID".

     2. PE1 MUST send a PW ATM service status indicating "ATM VC =
active"
        when AC1 is active at CE1.=20
        old state of AC1 =3D "INVALID"
        new state of AC1 =3D "STATUS-SENT"
        VPI/VCI =3D 1/33
        pwid =3D PW1

     3. PE2 on receiving a PW ATM service status indicating "ATM VC =
active"
        MUST send a PW ATM service status indicating "ATM VC status =
ack".
        VPI/VCI =3D 1/34
        pwid =3D PW1

     4. PE1 on receiving a PW ATM service status indicating "ATM VC =
status ack"
        should change the state of AC1 to "STATUS-ACK"=20
        old state of AC1 =3D "STATUS-SENT"
        new state of AC1 =3D "STATUS-ACK"
     =20
     5. PE1 on receiving a PW ATM service status indicating "ATM VC =
Active"=20
        when AC1 is in state "STATUS-SENT", should change the state of =
AC1
        to "STATUS-RCV" is active. PE1 should send "ATM VC Status ack"=20
        and "ATM VC active".
        old state of AC1 =3D "STATUS-SENT"
        new state of AC1 =3D "STATUS-RCV"
        VPI/VCI =3D 1/33
        pwid =3D PW1

     6. PE1 on receiving a PW ATM serive status indicating  "ATM VC =
status ack"
        should change the state of AC1 to "STATUS-ACK".
        old state of AC1 =3D "STATUS-RCV"
        new state of AC1 =3D "STATUS-ACK"

                       -----         =20
                     /       \            =20
         creation   |         |       =20
         ---------- |         v    =20
                     \   +--------------------------------+             =
    =20
                      ---|            INVALID             |
                         +--------------------------------+
                           ^                             \
                          /                               \     =20
                         /                                 \    =20
                        |                                   |    =20
   circuit inactive     |                                   |  snd "ATM =
VC active"
   ----------------     |                                   |  =
------------------- =20
                        |      rcv "ATM VC status ack"      |
                        |      -----------------------      v
                 +------------+                      +------------+
                 | STATUS-ACK | <--------------------| STATUS-SENT|=20
                 +------------+                      +------------+
                        ^                                   |
                        |                                   |   =20
 rcv "ATM VC status ack"|                                   |  rcv "ATM =
VC active"=20
 ---------------------- |                                   |  =
------------------
                         \                                 / =20
                          \                               /=20
                           \                             v
                          +-------------------------------+
                          |         STATUS-RCV            |
                          +-------------------------------+ <--+
                                                    /           \=20
                           snd "ATM vc Status ack" |             |
                           ---------------------   |             |
                             snd "ATM VC active"   |             |
                             ------------------     \           /
                                                      ---------

    7. PE1 MUST not retry sending PW ATM service status indicating " =
ATM VC active"
    8. Inactive Attachment circuit status can be indicated by sending =
following=20
       status codes at applicable
        0x00000002 - Local Attachement Circuit ( ingress ) Receive =
Fault
        0x00000004 - Local Attachement Circuit ( egress ) Transmit =
Fault

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

Changes to :

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

Document Title:
     IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)

Document Name:
                 draft-ietf-pwe3-iana-allocation-05.txt

LDP Status codes

       0x00000030   "PW ATM Service Status TLV

TLV Type

       0x096D       PW ATM Service Status TLV
        =20

PW ATM Service Status Codes

      0x00000020    ATM VC status ack=20
      0x00000040    ATM VC active
     =20

     =20

------_=_NextPart_000_01C4A14D.A0A3BAD8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------_=_NextPart_000_01C4A14D.A0A3BAD8--

---

From: Luca Martini <[email-masked]>
Date: Thu, 23 Sep 2004 08:59:34 -0600

Peter,
Given:
------------------------------------
"ATM n-to-one VCC and VPC Cell Transport"
This mode is similar to the ATM AAL5 VCC transport except that cells are
transported. Every cell that is received on a pre-defined ATM PVC, or ATM
PVP, at the ingress ATM port on the ingress PE, PE1, is encapsulated
according to [ATM], ATM n-to-one cell mode, and sent across the LSP to the
egress PE PE2. Grouping of ATM cells is OPTIONAL for transmission at the
ingress PE, PE1. If the Egress PE PE2 supports cell concatenation the
ingress PE, PE1, MUST only concatenate cells up to the "Maximum Number of
concatenated ATM cells in a frame" parameter received as part of the FEC
element.
---------------------------------------------------------

In the control protocol draft .... it does say "a pre-defined ATM PVC, 
or ATM
PVP"
that does not mean "one" for me .
Please note that I am not opposed in principle to having a trunk mode 
..... it will need to be a new PW type.
I would also like to know how a trunk would handle VP failures/alarms ...
( Neil , I'm sure you have an opinion on this point :-) )

Luca

Busschbach, Peter B (Peter) wrote:

>>>      3.  In case multiple circuits are getting mapped to a 
>>>      
>>>
>>pseudowire  ,
>>    
>>
>>>          carries the psedowire label , can be same for 
>>>      
>>>
>>different pairs of
>>    
>>
>>>     4.  In case a particular Attachment Circuit goes 
>>>      
>>>
>>inactive can the
>>    
>>
>>>          inform the remote end which Attachment Circuit 
>>>      
>>>
>>has gone down.
>>    
>>
>>> 
>>>
>>>      
>>>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 23 Sep 2004 11:17:37 -0400

> Sent: Thursday, September 23, 2004 11:00 AM
> To: Busschbach, Peter B (Peter)
> Cc: Agiwal, Manoj (Manoj); [email-masked]'
> FE C clarific ation

Do you really mean that "a" does not mean "one"? I interpreted "a" as "one", but used the following rationale to 'explain' that N>1 is supported: the fact that all cells of one pre-defined ATM VC are mapped onto a specific PW does not exclude that the cells of another pre-defined ATM VC are mapped on the same PW.

> I would also like to know how a trunk would handle VP 

In the upcoming MPLS Forum meeting, we will discuss a contribution that proposes a solution. I would be happy to share that with the PWE3 mailing list, but

a) I would first have to explain the precise definition of such trunk;

b) the only innovation that we propose, applies to the ATM Attachment Circuits. As far as the PW is concerned, we propose use of PW Status. Nothing new. 

Still, if you are interested, let me know.

> ( Neil , I'm sure you have an opinion on this point :-) )

We tried to anticipate Neil's comments. I think we can get away with the proposed solution without being reminded of G.805 :-)

> >I am not sure I understand this. I don't see anything in the 
> existing IETF drafts that limits the use of n:1 cell mode 
> encapsulation to a single VP.
> >
> >The MPLS Forum is working on an "ATM-MPLS Control Plane 
> Interworking" Implementation Agreement that, among other 
> things, defines the concept of Virtual Trunks. A Virtual 
> Trunk is a bundle of VPs that is encapsulated in a single PW. 
> >
> >Currently, a Virtual Trunk setup procedure has not yet been 
> defined, but there is no reason to believe that the PW 
> Control Protocol with Generalized FEC could not be used.
> >
> >Peter
> >
> >
> >
> >  
> >
> >>VC into one PW.
> >>
> >>    
> >>

---

From: Luca Martini <[email-masked]>
Date: Thu, 23 Sep 2004 16:45:05 -0600

>Do you really mean that "a" does not mean "one"? I interpreted "a" as "one", but used the following rationale to 'explain' that N>1 is supported: the fact that all cells of one pre-defined ATM VC ar…
Ooops, I meant to say it does mean one  ( the "not" slipped in by mistake )

>Still, if you are interested, let me know.
Yes , I am.  The question I have is the following:
Why do we have to transmit status of individual VPs in the LDP control 
protocol ? 
ATM does a pretty good job already ... If the PW goes down then we have 
to know the VPs in use , and generate the appropriate OAM F4 cells .... 
But the PW status down message is already there....

Luca

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 27 Sep 2004 22:38:53 -0400

> But the PW status down message is already there....

Luca,

Your comment is related to a discussion on ATM Virtual Trunks and OAM.

Let me explain the broader context. Manoj started this thread with a question about mapping multiple VPs onto a PW. You mentioned that only n=1 is currently supported in the atm-encap draft, upon which I made the point that you could interpret the draft as supporting n>1 as well. I referred to the work that is going on in the MPLS Frame Relay Alliance (MFA).

The MFA is working on an Implementation Agreement on MPL-ATM Control Plane Interworking. Among other things, it defines the concept of Virtual Trunks. A Virtual Trunk is a contiguous set of VPIs with a one ATM signaling and one ATM routing channel that run through the VP with the lowest VPI in the range. The ATM Switches at either end of the Virtual Trunk use the signaling channel to set up VPCs and VCCs through the trunk.

Virtual Trunks are primarily used in the following scenario:

ATM Switch 1   ---1--  PE1 ----2----  PE2 ---3--- ATM Switch 2

Interfaces 1 and 3 are ATM interfaces. 2 is the MPLS core. PE1 and PE2 are responsible for Pseudo Wire Emulation. 

A Virtual Trunk extends from ATM Switch 1 to ATM Switch 2. When the VT is provisioned, the PEs learn that all cells with a VPI in the range {L, U} should be mapped onto a specific Pseudo Wire using n:1 cell mode encapsulation. The PEs don't have to know the state of individual VCs. They are not involved in the setup of VPCs and VCCs. The only thing they do is mapping VPIs to Pseudo Wires Labels.

The two ATM Switches behave as if the Virtual Trunk is a regular interface between them. There is one routing channel to exchange topology information and one signaling for connection setup. ATM routing and signaling information is transparent to the LERs.

OAM for Virtual Trunks is still being debated in the MFA. I would rather wait with describing the full solution until we have agreement within the MFA. However, I can respond to your question "Why do we have to transmit status of individual VPs in the LDP control protocol?"
The answer is, we don't. The primary goal of Virtual Trunks is to define a solution in which the PEs are not aware of the status of individual VPs. Whatever solution the MFA comes up with, it will not require the use of PW Status notification for individual VPs within a Virtual Trunk.

Peter

[snipped to the end]

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 28 Sep 2004 18:14:43 -0400

Luca,

Regarding PW type:

If you use PW setup with PWid, I agree that 0x0003 could be used for any implementation that maps multiple VPs on a PW. However, for single-sided PW setup using the Generalized ID FEC, I think you need to be able to differentiate between true transparent cell transport as described in draft-ietf-pwe3-cell-transport-01.txt, and Virtual Trunks as defined by the MPLS Frame Relay Alliance. In the case of VTs, the egress PE needs to know that it will receive additional VT-related parameters from the ingress PE. (The exact procedures for signaled VT setup are not defined yet.)

As Andy Malis observed in a private email exchange, the MFA could use one of the First-Come-First-Served code points for a Virtual Trunk PW type.

Peter

> Sent: Tuesday, September 28, 2004 4:42 PM
> ok, I agree. you can actually use PW type 0x0003 today to 
> achieve this.
> PW type "ATM transparent cell transport" means that you can have a PW 
> that terminated into a virtual interface in a PE, and then you can 
> switch an arbitrary set of VPs into it.
> 
> Thanks.
> Luca
> 
> 
> >Let me explain the broader context. Manoj started this 
> thread with a question about mapping multiple VPs onto a PW. 
> You mentioned that only n=1 is currently supported in the 
> atm-encap draft, upon which I made the point that you could 
> interpret the draft as supporting n>1 as well. I referred to 
> the work that is going on in the MPLS Frame Relay Alliance (MFA).
> >
> >The MFA is working on an Implementation Agreement on MPL-ATM 
> Control Plane Interworking. Among other things, it defines 
> the concept of Virtual Trunks. A Virtual Trunk is a 
> contiguous set of VPIs with a one ATM signaling and one ATM 
> routing channel that run through the VP with the lowest VPI 
> in the range. The ATM Switches at either end of the Virtual 
> Trunk use the signaling channel to set up VPCs and VCCs 
> through the trunk.
> >
> >Interfaces 1 and 3 are ATM interfaces. 2 is the MPLS core. 
> PE1 and PE2 are responsible for Pseudo Wire Emulation. 
> >
> >A Virtual Trunk extends from ATM Switch 1 to ATM Switch 2. 
> When the VT is provisioned, the PEs learn that all cells with 
> a VPI in the range {L, U} should be mapped onto a specific 
> Pseudo Wire using n:1 cell mode encapsulation. The PEs don't 
> have to know the state of individual VCs. They are not 
> involved in the setup of VPCs and VCCs. The only thing they 
> do is mapping VPIs to Pseudo Wires Labels.
> >
> >The two ATM Switches behave as if the Virtual Trunk is a 
> regular interface between them. There is one routing channel 
> to exchange topology information and one signaling for 
> connection setup. ATM routing and signaling information is 
> transparent to the LERs.
> >
> >OAM for Virtual Trunks is still being debated in the MFA. I 
> would rather wait with describing the full solution until we 
> have agreement within the MFA. However, I can respond to your 
> question "Why do we have to transmit status of individual VPs 
> in the LDP control protocol?"
> >The answer is, we don't. The primary goal of Virtual Trunks 
> is to define a solution in which the PEs are not aware of the 
> status of individual VPs. Whatever solution the MFA comes up 
> with, it will not require the use of PW Status notification 
> for individual VPs within a Virtual Trunk.
> >
> >Peter
> >
> >  
> >
> >>    
> >>
> >[snipped to the end]
> >
> >  
> >
>