[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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

[SNIP]

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

Right. The region distinguishes only the switching capability.

Adrian