[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ASON reqts



Title: RE: ASON reqts

On #4, use of transport plane names is an important part of ASON architecture which separates control from bearer planes.  In G.7713.x we have the following text:

"Addressing of transport resources in the protocol is done by SNPP identifiers.  A pair of these would identify an SNPP link.  SNPP names are defined from transport name spaces (see Section 10, G.8080) and it is important to note that control plane names/addresses are not used for these.  For example, neither routing controller nor connection manager identifiers are used for bearer link names."

This affects things that describe the context of a GMPLS label.  For example, the hop objects in an explicit route.  They need to make sense to the transport plane in the absence of signalling.

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Thursday, May 15, 2003 18:52
To: Jonathan Sadler
Cc: Ash, Gerald R (Jerry), ALABS; ccamp@ops.ietf.org
Subject: RE: ASON reqts


Jonathan,

I've looked back over your posts, and have a few comments.

We agree with you that at this stage we should 'focus on the requirements, not the solution'.  Regarding your suggestions on the requirements, so far I think you've suggested 4 additional requirements:

1. Discussion of required behavior at E-NNI and UNI reference points. 2. Support for complete Call/Connection separation, including 0-connection calls 3. Explicit support for connection partitioning in different administrative domains.

4. Use of transport plane names instead of DCN addresses when referring to transport plane resources.

#2 is clear, and we agree to add '0-connection calls' to the requirements I-D.  #1, 3, and 4 aren't very specific/clear, and we'd like some clarification:

#1 What does 'required behavior' mean here?
#3 Connection partitions are not across ADs, perhaps this issue relates to session split across ADs? #4 We're using transport plane names, however GMPLS allows for both, perhaps this is an implementation issue?