[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] Re: Proposed text for the concatenation
>This is not describing just a way to use SONET/SDH as it changes every box
>in the network!
No, it doesn't change any box if you don't use these features. A feature in
GMPLS doesn't mean that you are obliged to use it or to implement it. But
which control plane will you use in your existing boxes ?
I don't think that you will have GMPLS as a simple software upgrade in your
existing ADM's. Obviously you will have to deploy a new cloud with boxes
able to run the control plane (in general you have a dedicated redundant
hardware to run the control plane and a dedicated redundant hardware to run
the routing algorithm in real-time on carrier class equipment's).
Interworking between an "ION" cloud and a non "ION" cloud (i.e. a
traditional SDH/SONET cloud) is another issue. In that case the control
plane doesn't run on the non ION cloud and you need a manual provisioning
there. Of course you must find a common denominator between the ION cloud
and the non-ION cloud to support end-to-end circuits. However, end-to-end
circuits that stay in the ION cloud will take benefits of the GMPLS features
implemented by your manufacturer.
>To use this there are changes/additions required to G.707 and G.783.
What is important for interoperability is not the definition of a concept in
a document but what is actually send between two nodes.
For arbitrary concatenation you don't change anything to the frame format,
only each node must be able to recognize and treat the pointers and the
VC-4-Xc. This concept is not defined in G.707 and G.783 but this has no
impact. You negotiate this capability between each pair of node, if there is
a node that doesn't support it, the circuit is refused. In addition, we
expect that you will know this capability for each node/interface via the
routing protocol. So the routing algorithm will find directly the adequate
Of course the ASIC's on that path must support the capability, this is an
ASIC implementation issue, not a document issue. A manufacturer can
implement whatever he likes in his ASIC's. GMPLS doesn't define what must be
implemented in the transmission plane to be interoperable (that's the job
for a profile). GMPLS gives tools in the control plane, some tools are
optional of course.
Transparency at the GMPLS UNI has absolutely no impact on existing
standards, the transmission plane and on existing ASIC's. It is only
implemented at NNI. At the UNI this capability is signaled in GMPLS and the
transmission plane doesn't care. At the NNI that will require a standard or
an implementation agreement if and only if multiple vendors are used. So
there are already many interesting scenarios in the short term where this
feature can be helpful. In the long term if you want to go to multiple
vendors you will need to ask them to reach a consensus to be able to
interoperate. That could be easier than you think because transparency is
software selectable for several of them, so when you buy the equipment you
specify where you want to tunnel the overhead bytes.
There is in fact absolutely NO interoperability issue with any of these
features if the circuit is refused when you try to cross a link where the
two ends are incompatible, or where on end doesn't support transparency.
Once again the routing protocol can advertise such capabilities. You can
keep the control of your network in any case.
All these features are "negotiated" when you try to open a circuit, if the
downstream node doesn't support a feature that connection attempt is
>I do not understand the linkage between GMPLS and concatenation. the two
>independent up to the point that you may wish to attempt variable bandwidth
>allocation. At this point extensions to concatenation are requires, and as
>have already stated this work is already under discussion in ITU.
GMPLS allows to open a circuit, that circuit can be a concatenated circuit
between two IP routers. Variable bandwidth is orthogonal with that feature
and is also possible with GMPLS if it can be supported by the control plane.
If you are referring to LCAS, this is not a control plane that allows to
open circuits dynamically.
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Tuesday, May 29, 2001 10:51 AM
To: firstname.lastname@example.org; email@example.com
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
This is not describing just a way to use SONET/SDH as it changes every box
in the network! To use this there are changes/additions required to G,707
Neither is this a new feature. Concatenation is already described and
I do not understand the linkage between GMPLS and concatenation. the two are
independent up to the point that you may wish to attempt variable bandwidth
allocation. At this point extensions to concatenation are requires, and as I
have already stated this work is already under discussion in ITU.
From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
Sent: 28 May 2001 12:06
To: 'Rob Coltun'; John Drake
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> Is it really that big an issue to just keep them in a separate RFC?
Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.
Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.
We already agreed on the following approach:
- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.
Can we simply use this approach ?
From: Rob Coltun [mailto:firstname.lastname@example.org]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
valid question - I don't think this is true for BGP. There are
to BGP that the working group has adopted.
Which TE drafts are you referring to?
We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
- whereas some of the functions aren't really new, and in cases might be
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.
Is it really that big an issue to just keep them in a separate RFC?
John Drake wrote:
> Why isn't the proposed disclaimer sufficient? If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors. I think the same is also true for BGP.
> -----Original Message-----
> From: Rob Coltun [mailto:email@example.com]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: firstname.lastname@example.org
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> despite the heated arguments I think the discussion is important to
> I suggest that instead of tagging non/pre-standard items in the current
> that they be put into a separate Informational document - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> but not as standard track documents.