Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

From: "Stephen Shew" <[email-masked]>
Date: Mon, 15 Nov 2004 15:46:52 -0500

See comments below:

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Thursday, November 11, 2004 21:18
> To: [email-masked]
> Cc: Shew, Stephen [CAR:QT00:EXCH]
> Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> Hi Stephen,
> 
> > I was not able to be at the CCAMP meeting today but do have some 
> > comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> Glad you were able to review the draft. Thanks for taking the 
> time. The slides for this and the other CCAMP drafts 
> discussed at the meeting can be found at 
> http://www.olddog.co.uk/61/ccamp.htm

Thanks, I've read them now.

> 
> > It seems that the 
> goals of the draft could be accomplished more simply 
> > by adopting the layer architecture as defined in ITU-T 
> Recommendations 
> > G.805 and G.809.  By doing this, the specific boundaries 
> between TDM, 
> > LSC, etc. don't have to be articulated as they are just layer 
> > networks.  Also, the designation of TDM does not include 
> the notions 
> > of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are 
> > important to transport equipment. Adopting the layer 
> architecture also 
> > enables a client layer to be supported by an inverse 
> multipling layer 
> > such as provided by Virtual Concatenation. Here a layer of finer 
> > granularity is use to support a layer of coarser granularity.
> 
> Thank you for the pointer to G.805 and G.809.  It is very 
> important to attempt to align the terminologies so that we 
> can discover whether the architectures are the same and 
> whether they are trying to address the same problem space. It 
> is also always good to try not to reinvent the wheel.
> 
> As you have no doubt noticed, the GMPLS architecture and 
> problem space require the capability to signal and route 
> across multiple instances of what the ITU-T terms a transport 
> layer. We would gladly look at any architecture you have in 
> this space. Can you point us at the ITU-T document(s) that 
> describe the architecture and solutions for routing and 
> signaling across multiple layers?

In ITU-T Q12/15, there is recent work on extending G.8080 to cover
interlayer call setup.  It is the aim of Q12 to have this work consented at
the upcoming SG15 meeting (Nov.29 - Dec.3).  If completed, I will ask the
Rapporteur to liaise this to the IETF so that the document can be shared.
In discussions at the previous SG15 meeting, two important interlayer cases
were identified which I think are of architectural importance.  First, the
case where a server layer connection is created that is then presented to a
client layer as a new client layer link.  I think this is exactly how FAs
from a "lower" switching capability are handled in the draft.  In transport
networks (with or without control planes), this is commonly done (e.g.,
creating an STS-192 trail from a DWDM path).  The second case is more subtle
and involves an adaptation of the client layer into a server layer without a
new client layer link being created.  For example, a virtual concatenation
layer over a regular SDH layer (e.g., VC3-3v over VC-3).  Here there are no
VC-3-3v links or switching points at all in the network.

As of the Q12/15 interim meeting (Oct.25-29, 2004), the G.8080 interlayer
material describes how a server layer call can support a client layer call
in a similar manner as a client connection would support a client call.  The
model recurses with G.805 layers and is in fact parallel to a TeleManagement
Forum TMF814 construct called the Physical Termination Point (a network
management construct that is most useful at the edge of a network) which
contains a "stack" of adaptations.

At this point, there isn't any interlayer routing work I am aware of in the
ITU-T and draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt certainly tackles that
head on.

My original comment was made to simply the description (and hopefully
solution) of the multi-layer problem.  In particular, inverse multiplexing
capabilities are probably important and the bearer architectures suggested
really do help this.  With virtual concatentation and TDM over pseudo-wires,
there isn't going to be a strict ordering of fine to coarse granularity in
multi-layer networks.  Adopting the suggested models accomodates inverse
multiplexing as well as future layer networks.

> Thanks,
> Adrian
> 
> PS As pointed out by several people in other emails, I'm not 
> sure if we mean exactly the same thing when we say 
> multi-region and multi-layer. It would be valuable if you 
> could read the GMPLS architecture RFC and the hierarchy draft 
> and comment on whether you see these terms in the IETF 
> context as matching perfectly with ITU-T terms.

OK, I shall look at them.  I understand that GMPLS architecture does
separate control from bearer and so I would hope that "multi-layer" remains
a bearer term as that is understanding in ITU-T.  I think the I-D uses that
semantic too.  As far a "region", I think the equivalent ITU-T G.8080 term
is "domain", of which there can be different types depending on  the control
function.  For example, a "routing domain", or "signalling domain".  It is
my understanding from reading the draft that "region" does not distinguish
between routing and signalling, and if so it may be helpful for creating
multi-service networks where the extent of the services does not have to be
the same while they may all use the multi-region path computation
capability.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Nov 2004 12:00:10 -0000

Stephen,

Thanks for the heads-up on the extensions to G.8080. It is good news that ITU-T is
considering how to handle interlayer call setup. Can you clarify whether this work covers
only calls or also includes connections?

It would certainly be good to have this work liaised to the IETF. It might even be nice if
it was liaised for discussion before it is consented although I realise that is not within
your personal remit.

Regards,
Adrian

> Rapporteur to liaise this to the IETF so that the document can be shared.

[SNIP]

> I understand that GMPLS architecture does

Right. The region distinguishes only the switching capability.

Adrian