While the name of the "GENERALIZED_UNI" object seems to refer to the UNI reference point, the purpose of the object is to carry attributes of a call. G.8080 states that SPCs still use Network Call Controllers (NCCs) in the process of setting up the SPC. Consequently, a call exists even for SPCs. Therefore, carrying attributes of a call is independent of whether the call was requested across a UNI or from a management system (ie. an SPC). I agree that the name of the object is somewhat misleading, but it comes from the fact that G.7713.2 attempted to reuse existing RSVP extensions as much as possible. (The name of this Call object came from the OIF UNI 1.0 IA)
The identification of the egress point in a carriers network to which an SPC is to be delivered is also a Call attribute, not a connection attribute -- it is independent of how a customer's service request is realized acrossed a service provider's network. However, the ERO is an attribute of a connection, not a call, and may not necessarily be passed over the E-NNI reference point. Consequently, the use of explicit label control in an ERO is not a possible way to handle SPCs that traverse an E-NNI. This is why the egress point identification appears in the call object in G.7713.2.
I hope this helps clarify SPC operations in G.7713.2/RFC 3474.
In my understanding, for the support of SPC connection, SPC_LABEL (Type=4, Sub-type=2)
subobject seems to be included in GENERALIZED_UNI object.
If my understanding is correct, I think there is a big ifference between concept of SPC connection and GENERALIZED_UNI object. SPC connection is NNI portion, not UNI.
As it is, GENERALIZED_UNI object describes originating and terminating UNI aspects between client and network nodes.
From logical view-point, in addition, the difference between switched connection (SC) and soft permanent connection (SPC) is where call and connection initiation is. In case of SC the initiation is of client node, but in case of SPC the initiation is of network node (of course, triggered by NMS). As a result, I think that GENERALIZED_UNI object and SPC connection could not be indicated by using the object, called GENERALIZED_UNI object because these are completely different by nature.
What do you think of my opinion?
º¸³½»ç¶÷: Adrian Farrel[email@example.com]
¹Þ´Â»ç¶÷: Ong, Lyndon
ÂüÁ¶:'Kireeti Kompella'; firstname.lastname@example.org
Á¦¸ñ: spc connections
¹ÞÀº³¯Â¥: 2003/11/13 ¸ñ 06:57
Thank you for raising this. There is certainly a lack of clarity in 3473 in this regard,
which is perhaps unfortunate.
In the earlier versions of the GMPLS work, this was made very explicit (sic) because
egress label control was invented before it was generalized to explicit label.
There is some reference to this in RFC3471 (of course, the function was originally
independent of signaling protocol), but no explicit procedures.
This descriptive deficiency has been addressed in draft-ccamp-gmpls-overlay. There is no
change in protocol to enable this function, merely a description of how it all works.
Hope this helps.
A couple of times now it's been suggested that Explicit Label Control is a way to
do SPC connections instead of the SPC_Label sub-object. I'm wondering if
people have a different model of SPC connections in mind. The procedures in
RFC 3473 for Explicit Label Control are as follows:
[when a label sub-object is present] If the U-bit of the
subobject being examined is clear (0), then value of the label is
copied into a new Label_Set object. This Label_Set object MUST be
included on the corresponding outgoing Path message.
If the U-bit of the subobject being examined is set (1), then value
of the label is label to be used for upstream traffic associated with
the bidirectional LSP.
Neither of these would seem to help you for SPC, since there is no outgoing PATH
message at the network endpoint, the endpoint call control is handled by
the management system and not using a UNI or overlay interface (at least
as defined in G.8080).
Explicit Label Control seems like it would help you control the label assignment
within the signaled portion of a connection.
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.