Re: Moving right along ...

[Sudheer Dharanikota <sudheer@nayna.com>]

Hi Zhi:

Thank you for taking time in writing this informative mail.
Few of my opinions and questions are inline...
Please let me know if I am wrong with any of the assumptions.

For those who are interested in ASON architecture refer to
http://http://www.t1.org/filemgr/FileList.taf?Directory=t1x1%5Cx1.5&ShowTitle=New%20T1X1.5%20Files

Of course, the version on this site is old . But this may be
good enough to start some technical discussion. Hopefully
ITU will provide an updated version soon for IETF public.

Zhi-Wei Lin wrote:

> Hi Sudheer,
>
> OK I'll try to highlight some. I think Maarten mentioned one already:
> -- ASON is based on a separation of layer network.
>
> Not only that, ASON is also based on separation of functional roles of
> the switched network. ASON defines the architecture of the switched
> network in terms of the interactions of different components. Components
> defined by ASON performs specific tasks:
>

Agreed on ITU/ANSI approach to define ASON. To compare ASON
requiremetns with what GMPLS provides, we need to see if all these
components are present in what is supported by GMPLS. I would assume
this is not an issue if GMPLS has all the components defined by ASON
(G.808 V0.8.2).


> --Call controller (CallC) is the "service" component that interfaces
> with the user to support service requests. I believe this can be viewed
> as been handled by the OIF UNI specification, which provides the user to
> network request capability

Well then - this is not an issue. Because OIF UNI is already using GMPLS
extensions to support CallC functions. There are plans to enhance OIF UNI
to what ever functions that are missing either using Private UNI or others.
Of course we can always discuss this on OIF mailing lists and at the meetings.

>
> --Connection controller (CC) is the network component that supports the
> connection operations, which includes setup and release of individual
> links (ITU: link connections) in support of the user request. A set of
> connection controllers are involved on a sub-network (area of AS) basis
> to set up/release connections within its domain of responsibility, and
> interacts with other CC in different ways depending on how the operator
> configures the interactions. Methods of interaction include a joint
> federation model and a cooperative federation model. CC is I think what
> GMPLS is about, in terms of setting up and releasing/tearing down
> connections.

Agreed that CC is what GMPLS 'signaling' is all about. Currently (untill
inter-area
TE model is finalized) IETF is working with one area. GMPLS does not
assume how to and where to expand loose segments of a path. So a CC
can be placed anywhere in an area. This path computation can be in an NE
or outside NE. So, in my opinion, this model supports both joint and co-operative
federation models. of course, it has to have all the primitives to manage a
connection. Let me know if I missed any particular scenario.

> --Link resource manager (LRM) is the network component that assigns a link
> (ITU: link connection) from a link bundle/TE-link (ITU: link). Thus the
> progression of signaling goes from CC which receives requests for
> connections to LRM which chooses a link, and provides the CC with the
> requested link information so that CC can set up a sub-network
> connection (a connection across a sub-network). Note that sub-network
> connection "concept" is a recursive definition where the limit of
> recursion of a sub-network connection is the fabric connection. The LRM
> from GMPLS perspective is subsumed into the CC (this is where the label
> negotiation takes place).

I may not be catching all the issues here. I know what you mean by sub-network
connections (SNPs) and their recursive nature. But why do you think this is
not supported by current bundling and hierarchy concepts at IETF?

> --Routing controller (RC) is the network component that provides the
> routing information, including route dissemination, route determination,
> route table update, etc. Three models of routing has been defined:
> hierarchical, source-based and step-by-step. As part of the routing
> definition, a "routing area" is defined to support
> multi-level/hierarchical routing domains. This is very similar (maybe
> identical?) to the OSPF/BGP separation of roles.
>

Agreed that RC is GMPLS 'routing' component. As you know step-by-step
and source-based are supported currently by IETF. Some work is
going on on hierarchical (inter-area, SRG etc.). Hope we cover all the cases
needed for the hierarchical requirements here.

>
> NOTE that these are all logical components (what ITU calls a
> computational view of the control plane), with certain distribution
> assumed (what ITU calls an engineering view of the control plane).
> Different implementations of these components may have, e.g., CallC, CC
> and LRM all in one "box" while another implementation may have CallC in
> one box and CC, LRM and RC in another box. However, the functionality is
> equivalant. Only difference is in terms of which interfaces have been
> exposed and becomes external (that is standardizable).
>

I see. Why don't we concentrate on this topic and discuss what are the
possible combinations and advantages? Coming from the router world
I belive these should be internal to increase the efficiency of operation.

>
> Now to how different or similar is ASON/G.dcm with GMPLS. In terms of
> the information mapping and message mapping between them, I would say
> they are very close to each other. For example, when ASON/G.dcm
> discusses setup/release operations, it views the transport resources as
> an "abstract" entity called SNP (subnetwork point). If you are familiar
> with management objects, the SNP is very similar to SNTP (subnetwork
> termination point). Where SNTP provides the management system with a
> view of the underlying transport resources (CTP or TTP or simply TP),
> the SNP provides the control plane with a view of the underlying
> transport resources. As such these SNP and SNPP (SNP pools which is an
> aggregation of the SNPs into a logical "bundle" based on some policy or
> provisioned constraints) is used in setting up a connection. The
> SNP/SNPP provides an abstraction barrier between physical resources and
> logical resources and is provided on a layer basis (i.e., SNP ID
> information for a STS-1 layer is independent of the SNP ID information
> for a STS-3c layer is independent of the SNP ID information for a ODU1
> layer).
>

Agreed with the concepts. It was tough to read CCITT documents in 1990
and it is tough to read ITU documents now :-) (pun intended). They are
very formal documents and cover all the cases. But this is not an issue for a
discussion I hope.

> The other difference is that ASON/G.dcm deals with abstract "names" in
> terms of specifying relevant endpoints. This is simply a "protocol
> neutral" aspect of addresses used in GMPLS, where GMPLS assumes IPv4 and
> IPv6, G.dcm does not assume any addressing scheme. This is not
> inconsistent, only different levels of specification. One of the "names"
> defined in ASON/G.dcm is a "call name" which is a reference to the call.
> IETF GMPLS I believe "sort-of" supports this. Call name is essentially a
> globally unique identifier that identifies the call. IETF GMPLS also
> provides a globally unique identifier in the form of SESSION and
> SENDER_TEMPLATE (for RSVP-TE).
>

My opinion on addresseing:
IETF may be interested in IPv4 or IPv6 address space for reasons that it can
control the allocation and there was no need to use other address space. It is
a good idea from the deplyoment point of view also. Please do not crusify
me for this.

With your observations on call naming support in GMPLS... naming is not
an issue with GMPLS.

>
> There are also capabilities described in GMPLS that is currently not
> specified by the ASON/G.dcm. This includes the capabilities supported by
> the Admin_Status object (turning on/off monitoring), and the multiplier
> parameter within the SONET/SDH SENDER_TSPEC/FLOWSPEC object. For
> example, many of the parameters that support the SONET/SDH connection
> (such as what signal type, encoding type, NCC, NVC) are implied
> information in ASON/G.dcm since they are layer information. These
> parameters in GMPLS may be thought of as an implementation of the layer
> information for the specific protocol.
>

So are you are saying is GMPLS has more than required? This cannot be
a drawback in the worst case :-)

A comment on the additional parameters...  you are assuming that a layer
boundary is a domain boundary and there is no need to calculate a TE
path through these boundaries. Is this a valid assumption?

>
> GMPLS RSVP-TE is a soft-state protocol, CR-LDP is more a hard-state
> protocol. ASON/G.dcm does not specify whether the protocol needs to be
> soft-state or hard-state. It discusses what are the behaviours and how
> these "systems" may recover from problems. It also provides a high-level
> state transition diagram on the operation of the signaling mechanism.
>  From this viewpoint, I also don't see too much inconsistency. Of
> course, I haven't done any analysis/comparison. If anyone is interested
> doing this it let me know!
>

So this is also a non-issue.

>
>   The first stage of the ITU specification for the ASON work is nearing
> completion. The next stage is to start work on the protocol specific
> implementations of the ASON model. At the current ITU meeting, we
> already have United Kingdom (presented by British Telecom) bring in
> contribution requesting to use PNNI as A protocol for supporting ASON.
> This was also supported by other carriers. The ITU has now opened the
> floor to any other protocols to be submitted as well.
>
> So if people want to see GMPLS considered as one of the protocols for
> ASON, someone needs to submit this to the ITU. Currently the decision is
> that if any protocols meets the requirements outlined in ASON and G.dcm,
> then they will be considered (i.e., any protocol). There were some
> interest shown in the meeting to bringing in GMPLS.
>

Well GMPLS is satisfying most of the ASON requirements. Why not this is a
potential candiadate for submission at ITU? May be the WG chairs have a
plan on how to proceed.

>
> Well, I hope this provides enough of a summary to help the discussions
> along.
>

Thank you for the summary Zhi. Please contribute to this mail thread to
narrow down the issues.

Regards,

sudheer

>
> Zhi
>
> Sudheer Dharanikota wrote:
>
> > Hi Zhi:
> >
> > Zhi-Wei Lin wrote:
> >
> >
> >> From what I understand G.ason and G.dcm is developed to describe the
> >>process and the minimal requirements needed to support a basic switched
> >>transport service. GMPLS is a protocol specific implementation that will
> >>likely meet many of the requirements, and may have some minor areas that
> >>it does not meet. Then the question to ask (as with any requirements and
> >>architecture work -- I'm sure we all have architects in our company) is:
> >>how critical are the requirements that may not be met and what changes
> >>are needed to GMPLS (if any) in order to meet them?
> >>
> >>
> >
> > It may be a good idea to explain where GMPLS is lacking in meeting ASON
> > and DCM requirements. YOu, being involved in this process, is the best
> > person to articulate the major drawbacks. WHy don't you spend a minute in
> > higlighting them.
> >
> > THese discussions are becoming highly non-technical and unproductive. Let us
> > streamline our energy to a common cause - find the enhancements needed to
> > accomodate ASON architecture.
> >
> > Regards,
> >
> > sudheer
> >
> >
> >>
> >