See comments below:
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Thursday, November 11, 2004 21:18
> To: ccamp@ops.ietf.org
> 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 creat! ed. 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.