Subject: RE: Koleyni and Bocci drafts

From: Keith Knightson <[email-masked]>
Date: Mon, 24 Jun 2002 18:21:59 -0400

Folks,

I have some comments  on what Maarten and Neil wrote

Regards

Keith

At 11:58 AM +0200 24/6/02, Maarten Vissers wrote:

>>  G.805 03/2000 contains a section 5.5 on layer network
>>  interworking. This
>>  describes what is referred to in FR/ATM interworking as
>>  "service interworking".
>>  The other "interworking" case referred to as "network
>>  interworking" isn't a real
>>  interworking case... it is a straight client/server case.

At 10:09 PM +0100 24/6/02, [email-masked] wrote:

>NH=> Not sure who came up with these terms but they are really poor at
>conveying the real arch behvaiour of the 2 cases.  There is prot-conv and
>client/server I/W for the data-plane, and similar considerations also apply
>for the control-plane.  Restricting attention to data-plane, in both
>prot-conv and client/server cases one *must* take dynamic defect handling
>into account...but they are quite different (see my recent posting to Khalid
>on this).
>>

KGK writes:

I would contend that interworking, of both types,  as being necessary 
when an end-to-end path is required across two networks that have 
different native protocols. So if one is ATM (X) and the other is 
MPLS (Y), say, then interworking is necessary. It has nothing to do 
with client/server as such, it has everything to do with overcoming 
the discontinuity that would otherwise occur between the X network 
and the Y network. Ie. without interworking no path across the 
combination of the X network and the Y network would be possible. 
That's why all these cases may be considered to be interworking.

Then we have the two possible solutions for solving the discontinuity 
between the network with X and the network with Y, mapping X to Y 
(service interworking) or carrying the focus protocol X over focus 
protocol Y (network interworking).

Of course, the control and managment planes need to be taken into 
account in any interworking situation. However, I do not think this 
is so clear cut or so simple as to mean that a single solution suits 
all cases. To "violate"  some artificial/religious notion of what's 
legitimate, or not, may well depend on the precise case and condition 
under consideration and the practicality of the various solutions 
proposed.

Regards

Keith

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 25 Jun 2002 12:26:25 +0200

Neil,

[email-masked] wrote:
> 
> Hi Maarten.....see in-line...regards, Neil
> 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: 24 June 2002 10:59
> > To: Khalid Ahmad
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: [PWE3] Koleyni and Bocci drafts
> >
> >
> > Khalid, Neil,
> >

The service interworking (or any better term for this) case will be complicated
if the OAM/OH and defect handling of the two layer networks are not 1:1
compatible. The resulting hybrid trail fault/performance capabilities will then
most likely be worse than the fault/performance capabilites of each of the
individual layer networks. That's the price to pay when you do not want network
interworking (and thus a larger stack).

> >
> > So, if an ATM VP is transported as is over an MPLS trail,
> > then MPLS is just
> > another Transmission Path layer, and all ATM requirements for
> > TP/ATM_A_So and
> > TP/ATM_A_Sk in I.732 apply to MPLS/VP_A. ATM VP is then a
> > client layer of the
> > MPLS layer.
> NH=> Correct.  But it still requires that MPLS defects get mapped to correct
> ATM VP/VC FDI at LSP trail term points.

Indeed, when e.g. a VC-4 trail fails, all ATM VP connections over it will have
to get VP-AIS inserted. These VP-AIS signals then get muxed and mapped into the
MPLS trail; and vice versa, if the MPLS trail fails all ATM VP connections will
have to get VP-AIS inserted. These VP-AIS signals then get muxed into the VC-4
trail.

Similarly, when the ATM VP trail fails, all ATM VC connections over it will have
to get VC-AIS inserted. These VC-AIS signals then get muxed and mapped into the
MPLS trail; and vice versa, if the MPLS trail fails all ATM VC connections will
have to get VC-AIS inserted. These VC-AIS signals then get muxed into the ATM VP
trail.

> >
> >        -------------------------------------------
> >        |                  VP_C                   |
> >        -------------------------------------------
> >       |||||||          |||||||
> >       TP/VP_A         MPLS/VP_A
> >          |                |
> >        TP_TT           MPLS_TT
> >          |                |        ||||||||||||||||||
> >                       ----------------------------------
> >                       |           MPLS_C               |
> >                       ----------------------------------
> >                               |||||||||||||||||||
> >
> > If ATM VC is transported as is over an MPLS trail, then the
> > MPLS is just another
> > version of the ATM VP layer. ATM VC is then a client layer of
> > the MPLS layer.
> > The ATM VC requirements for VP/VC_A_So and VP/VC_A_Sk in
> > I.732 apply to
> > MPLS/VC_A.
> NH=> Yes
> >
> >        -------------------------------------------
> >        |                  VC_C                   |
> >        -------------------------------------------
> >       |||||||          |||||||
> >       VP/VC_A         MPLS/VC_A
> >          |                |
> >        VP_TT           MPLS_TT
> >          |                |        ||||||||||||||||||
> >       TP/VP_A         ----------------------------------
> >          |            |           MPLS_C               |
> >        TP_TT          ----------------------------------
> >          |                    |||||||||||||||||||
> >
> > If ATM VP is continued as an MPLS signal (case of service
> > interworking),
> NH=> This is *not* yet defined......though it does offer up some interesting
> evolution issues.

And most likely some headaches due to some of the differences between ATM and
MPLS OAM and defect handling... :-)

> > then
> > the ATM VP characteristic information is to be continued as
> > MPLS characteristic
> > information as described in 5.5/G.805. This implies that the
> > VP OAM is converted
> > into MPLS OAM and the VP payload is continued as MPLS payload
> > (and vice versa).
> NH=> I agree the payload should be carried over transparently.....in fact
> this 'payload' represents the common end-end trail that spans both ATM/MPLS
> regions.  This could be AAL5 for example. However, the ATM cell level OAM
> has no relevance to the MPLS OAM (these are kept disjoint since at this
> level the network trails are peers).  Also see my response to Khalid.

For the case of ATM VP - MPLS service interworking, the payload contains ATM VC
signals.
For the case of ATM VC - MPLS service interworking, the payload contains the AAL
signal(s).

So for the latter ATM VC- MPLS service interworking case, the ATM VP OAM is
server layer OAM and doesn't play a role in the service interworking. The ATM VC
OAM however will have to be converted into MPLS OAM (and vice versa). If the
MPLS signal is now muxed/mapped into a MPLS tunnel trail, then the ATM VP and
that MPLS tunnel are peers.

Regards,

Maarten 

> <snipped to end NH>