Re: Moving right along ...

[Zhi-Wei Lin <zwlin@lucent.com>]

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:
--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
--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.
--Link resource manager 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).
--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.

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

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

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

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.

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!

  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, I hope this provides enough of a summary to help the discussions 
along.

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