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

Re: spc connections

ben, see in-line

Ben Mack-Crane wrote:

Dimitri Papadimitriou wrote:

ben,

your response is confusing what you say is that
the operator at the as boundary can accept a call
that specifies accessing a specific end-point but
does not accept the connection request associated
to this call - does this make any sense ?


Yes, it does.  For instance, an operator receiving a
request for an Ethernet P-P call (service) may decide
to deliver that service over a lambda network or over
a SONET/SDH network using virtual concatenation.


this confirms that the delivery of the ethernet end-
to-end "connection" may include a single object ERO
being the last hop, now that this triggers internal
SDH switched connections this is up to the internals
of the network, but remark here that there is by no
way a control plane driven "call establishment" except
if you were referring to a client initiated switched
connection which is not the case seeing the title of
this thread - first clarification

Thus the connection(s) used to realize the service (call)
may be quite different.  Separating call attributes
from connection attributes so that they can be easily
distinguished contributes to a simpler protocol
(and simpler implementation).


i took a look back at G.7713 and it mentions, that
"To support Soft Permanent Connection (SPC) service,
the Call Process is handled by the management plane,
with management requesting the CC to establish
connections in support of the call." there is no
mention about calls processed by the control plane
for spc's - second clarification

note: CC = Connection Controller

more fundamentally, i don't see where the delivery
of call functionality for spc's does have to imply some implementation specific restrictions to fulfil
this functional requirement ? when you point out
here that the "ERO may be disregarded" it becomes
a protocol requirement not a functional requirement
and afaik G.8080 does have nothing to do with any
implementation specifics

As you say, while it is a requirement that call/connection
separation is provided for SPCs as well as SCs according to G.8080,
this does not create a protocol requirement per se.


in particular for SPCs for which the call are processed
by the management plane, the network switched connection
being processed by the control plane

My observation is simply that the protocol design will
benefit from separating call and connection information
as this leads to a protocol that simply meets the requirement.
Other (more complex) protocol designs are possible,
though I would like to avoid them.


since there is no "control plane driven call" in spc,
such considerations boil down in delivering protocol
design that supports SP *Connection*

your proposal can also be put in the basket of "add more
objects to make it less complex" however this is still
to be demonstrated

now concerning the source of information, you're
mismatching what lyndon said "passing information
from the management to the control plane" with the control plane exchange of information between call/connection controllers 

the whole discussion point has been raised because lyndon
made a distinction in ways for setting up SPC's (from the
source of the end-point information) not the one you're
bringing up here

I'm not certain I understand your point here.
I think principles of good information structure apply in any case.


that the process of establishing the SPC is independent of
the way management process the associated call, yes this is
certainly true, that you want to use the control plane for
these calls this seems in contradiction with G.7713,

also, i'd like also to mention that there is a difference in
- the end-to-end association between the edge permanent connection
  and network switched connection (= spc)
- from the establishment of the switched connection within the
  network itself

the conclusion, as also drawn by several people on
this list seem clear:

"There is no change in protocol to enable this function, merely a description of how it all works."

something that will be addressed in order to avoid
spreading of misunderstanding


note that this conclusion still holds and is in imho addressed
by the text proposed by kireeti

thanks,
- dimitri.


Dimitri,

The reason that the SPC Label (or Egress Label) should be in a separate object from the ERO
is that the ERO may be ignored.

This is not unrelated to the source of the information, in that the ERO is provided by some
network control or administrative entity while the call endpoint identificaiton is provided by the entity
requesting the service. In fulfilling a service request, a service provider may disregard the ERO
but may not disregard the service request. Thus it makes perfect sense to keep these pieces
of information in separate objects.

Regards,
Ben

Dimitri Papadimitriou wrote:



lyndon, the fact that you may receive the "information" from an nms/ems, manually configured, or any other means does not have to impact the external behaviour of the protocol - what you suggest is the use of a
mechanism that would depend on the originator of the "information" -

while rfc 3473 specifies in section 5.1.1:
"Procedures by which an LSR at the head-end of an LSP obtains the
information needed to construct the Label subobject are outside the
scope of this document."

the only thing that needs to be specified for this subobject is the
placement and ordering in the ERO (as specified in the same section)

in addition - and as far as my understanding goes - there are no functional requirements mandating - this should be somewhat obvious -
the implementation specific mechanism you describe here below

hope this will help you to understand what we're trying to explain
you since last monday (john, adrian, etc. via private and public
e-mails)

thanks,
- dimitri.


<snip>




-----------------------------------------
============================================================
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
============================================================



--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491