RE: ASON reqts

["Ash, Gerald R (Jerry), ALABS" <gash@att.com>]

Yangguang,

> > SPC is required by ASON, it was included in the first 
> > Recommendation on Requirements for the Automatic Switched 
> > Transport Networks (G.807 published in 2001).  For operators, 
> > SPC support is considered as a critical application for ASON. 
> > Until UNI/E-NNI support functionality is available (e.g. 
> > billing systems/directory services), this will likely be the 
> > first application for most operators of ASON.  For example, 
> > in ITU-T Rec'd G.7713.1 on ASON PNNI (consented January 
> > 2003), it is only concerned with specifying soft permanent 
> > connections.

> I wasn't challenge SPC at all. I was just wondering the first 
> requirement to GMPLS signaling in the draft is necessary. 
> Because I know two solutions don't do that but can still 
> provide full SPC service well.

The 'first requirement' is for SPC, and as I pointed out is a MUST requirement for ASON (see the summary of ASON requirements/'identified gaps' at http://ietf.org/proceedings/02mar/slides/ccamp-4/sld005.htm.)

> > Again, ASON requirements/'identified gaps' include 
> > crankback as a MUST, inter-domain and intra-domain.  It is 
> > already included in G.7713.1 and G.7713.3.  More information 
> > on crankback is available in the draft 
> > http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-05.txt.

> SPC is a service. Yet crankback is a mechanism. Not sure why 
> requirement wants to enforce a mechanism/solution.

I think they're both mechanisms that could possibly support a service.  The ASON requirements draft is identifying delta requirements in terms of the GMPLS protocol capabilities, not necessarily limited to services.

Thanks,
Jerry