RE: Overlay draft and OIF history...

["Brungard, Deborah A, ALASO" <dbrungard@att.com>]

The support of non-IP addresses was to support non-IP clients e.g. either within the network (I-NNI) or over the public UNI (e.g. ATM equipment with SONET interfaces, SONET equipment). A multi-service architecture.
 
Overlay and peer terminology has become very confused between IETF/OIF/ITU. In ITU-T, we discuss Public UNI, E-NNI, I-NNI. Most of our effort in ASON is to distinguish E-NNI/Public UNI from I-NNI as we (ITU) need to distinguish what is needed to support inter-operability (inter-domains/inter-operators) without constraining our choices for intra-domain implementations. For E-NNI and UNI, as already noted, it is untrusted i.e. overlay. For I-NNI, ASON does not limit an operator's choice - it is considered intra-domain. The current definition of the I-NNI is based on peer but there is no intention to limit an operator's choice for intra-domain - either or both overlay and peer models may be used. And for all three, the definitions are soft depending on the level of trust/applications.
 
Early discussion on the exploder also discussed overlay and peer in reference to the transport layers e.g. IP/SONET. Because of the multiple possibilities which network equipment can support and use of the equipment in a network (P-UNI/E-NNI/I-NNI), ITU-T defines separately the layers as overlay. For definition. Again, no intention to drive specific implementations.
 
Considering the overlay-draft applications, it is appropriate as an IETF work item.
 
Deborah
 
 

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Greg Bernstein
Sent: Wednesday, December 04, 2002 11:10 AM
To: ccamp@ops.ietf.org
Subject: Overlay draft and OIF history...



Hi all, it's great to see a draft and this much support for a UNI model which seems necessary when offering support out to the edge of "connection oriented services".  

 

This is very similar to the original OIF UNI work, until a huge issue arose over supported address types.  The initial thrust was for only IP address types (v4 and v6).  However this didn't fly with a bunch of folks with installed networks using NSAPs.  However it was never really clear, to me, that NSAPs were needed, i.e., the optical control plane was to be IP based and any other "addresses" could be viewed as "names" and translated when and if necessary.  Note that all previous SONET/SDH standards specified OSI stacks on the "in band" data communications channels (if you were wondering how we got into this mess).

 

This is an area that could use a bit of thinking since from the ITU-T perspective other (non IP) address are desirable.  And it would be nice to harmonize the work at the various standards bodies.

 

Greg B.

 

Greg Bernstein, Grotto-Networking