Re: spc connections

[Jonathan Sadler <jonathan.sadler@tellabs.com>]

Hi Deborah -

"Brungard, Deborah A, ALABS" wrote:

> It's been a long thread and I am not sure anymore what we are discussing:
>
> - use of the ERO for SPC? Can you be more specific on your concerns as this is where OIF/ITU chose for a different implementation. We need to understand if it resulted from an unclear description or technical concern (as both Yakov and Kireeti requested).

As pointed out in previous emails, the ERO is a Connection object (corresponding with G.7713's Explicit Resource List), while the identification of the link connection to be used at the far end of an SPC is a Call parameter.  This identification has no relevance to any of the connections used to deliver the SPC, making it reasonable to put it in the Call object (aka. Generalized UNI object).

As also pointed out in previous emails, neighboring domains may enforce a high trust boundary, resuting in EROs being ignored since they prescribe the resources to be used in the neighboring domain when routing a connection.

Finally, two neighboring domains involved in routing a call are allowed in G.8080 to use private name spaces for their SNPs.  This privicy may be used to facilitate information hiding, or to eliminate the need for internal name coordination.  The ERO causes problems with this as it requires SNP names to be exposed, removing the ability keep such naming private.

These are some of the reasons that the OIF/ITU chose a different implementation than what has been discussed recently on the list.

> - use of G7713.2 (3474) as a solution? This is also a needed discussion item to progress the ASON signaling work.
>
> On the use of G7713.2: we all agree it provides a *solution*. The question is - is a G7713.2 network overlay (not to be confused with the GMPLS overlay model) the only solution needed? Or do we need a 3473 solution?

As stated in the 3473/3474 draft, the solution in G.7713.2 is not incompatible with nodes only implementing 3473.  These nodes may sit between two G.7713.2 speakers with no problems.

> Your 3473/3474 interworking draft and the new appendix added to the draft on GMPLS signalling for ASON both describe the 3473/3474 differences. The key driver for defining new 3474 objects was the implementation decision to support multiple addresses (IPv4, IPv6, NSAP) in the protocol objects (vs. address mapping at ingress/egress (e.g. G7713.1 ASON PNNI's implementation)).

Actually, the key driver for new objects was the introduction of calls.  The fact that endpoint addresses used for calls may take format other than IPv4 was in response to carrier's requests.  Placing these addresses into the call object is appropriate as they are not necessarily the endpoints of individual connections.

As for your characterization of G.7713.1 as "simpler", there are a number of reasons that G.7713.1 didn't need to make a large number of changes.  Specifically:

  o G.7713.1 did not need to introduce IEs to handle the
      call/connection separation already in PNNI.

  o G.7713.1 utilizes NSAP addresses for endpoint addressing
      for which IPv6 is a subspace (AFI=35, see
      ISO 8348/Amd.1:1998).  IPv4 is a further subspace of
      IPv6.  (See IPv4-mapped IPv6 addresses in RFC 3513)

      Consequently, no additional address formats needed to be
      introduced in G.7713.1.

Please also note that G.7713.1 scope is limited to SPCs, not Switched Connections.  (This is stated in the summary for the document.)

It is interesting to note that the specification of SPC endpoints (ie. the Calling and Called Party Number IEs) is still done with Call information, and not SNP names.  Further note that the egress link connection is not specified using the DTL (PNNI's equivalent of G.7713's Explict Resource List).

I hope this brings some clarity to the discussion.

Jonathan Sadler

>


-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================