5 May 2003 16:26
RE: ASON reqts
Ash, Gerald R (Jerry), ALABS <gash <at> att.com>
2003-05-05 14:26:28 GMT
2003-05-05 14:26:28 GMT
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
RSS Feed