Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control

["Vishal Sharma" <v.sharma@ieee.org>]

Hi Alex,

In response to the feedback from the RTG-Area Directorate, please find
attached our responses about how we intend incorporating their
feedback.

BTW, thanks to the Directorate for their careful review of the document
and their feedback, we think it will help improve the doc. further.

Once we receive a confirmation that these additions look good, we
will modify the draft, and repost to the IETF drafts directory (I
am assuming that is the next step), and cc  you.

Thanks,
-Vishal, Greg, Eric


> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Alex Zinin
> Sent: Thursday, March 04, 2004 4:49 AM
> To: ccamp@ops.ietf.org
> Cc: Rtg-dir@ietf.org
> Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> Folks-
>
>  Please find below comments from the RTG area directorate that I would
>  like the WG to consider.
>
>  Thank you.
>
> --
> Alex Zinin
>
> Technical:
> ----------
>
> Section 3.2:
>
> 1. Figure 1 misses the STM-0 branch

Thanks for noticing! We will add this using G.707.

> Section 3.4.3:
>
> 2. In comparison table, PNNI word appears for the first time in this
>     document, any specific reason to mention PNNI in a GMPLS context ?

The intent here was just to ask whether a packet-based control
plane was valuable for advanced TDM service provisioning and mgt.
We could reword this to
"Packet-based control plane (like MPLS or PNNI-based) useful?"

> Section 3.5
>
> 3. "New simplified encapsulations could reduce this overhead to as low
>     as 3%, but the gain is not huge compared to SDH and SONET, which have
>     other benefits as well.)" any reference available for these new
>     simplified encapsulation(s) ?


I believe Eric might be able to locate a reference for this. If not, we
will remove in the revised version.

> 4. "Any encapsulation of IP over WDM should at least provide error
>     monitoring capabilities (to detect signal degradation), error
>     correction capabilities, such as FEC (Forward Error Correction) that
>     are particularly needed for ultra long haul transmission, sufficient
>     timing information, to allow robust synchronization (that is, to
>     detect the beginning of a packet), and capacity to transport
>     signaling, routing and management messages, in order to control the
>     optical switches."
>
>     The first part refers to data plane capabilities, however the
>     requirement: the "encapsulation of IP over WDM" should deliver
>     the capacity to transport IP based control plane information -
>     why is this the case ? an out of band network would also do the
>     job and this statement makes thus the implicit assumption that
>     data and control plane topology is congruent

This is an accurate observation.
However, since standardization of IP over WDM without SDH/SONET
is beyond scope here, this could be removed. Although, there still
tends to be confusion when there is talk of "putting IP over lambda",
which does not happen directly.

Alternatively, we could reword this to decouple what
is needed in the data plane from what is required in the control plane,
and mention, in fact, that associated signaling is not a requirement
for GMPLS-based control of SDH/SONET networks, merely one option, and
mention non-associated signaling as the other.


> Section 6:
>
> 5. "Due to the increase in information transferred in the routing
>     protocol, it may be useful to separate the relatively static
>     parameters concerning a link from those that may be subject to
>     frequent changes. The current GMPLS routing extensions [12],[13],
>     [14] do not make such a separation, however."
>
>    it may be thus worth asking the question was the dissemination
>    of these quasi-static "link capabilities" using the same rules
>    as for any other TE LSA Type 1 sub-TLV the right approach ?

From the carriers perspective, the up-to-date dissemination of all link
properties is essential and desired. The use of a link-state routing
protocol to distribute this information provides timely and efficient
very frequently, it makes sense, from an efficiency point of view, to
separate them out for update.  This situation is not yet seen in
actual networks, however if GMPLS signaling is put into widespread use
then the need could arise.


> Section 6.1:
>
> 6. what does the following sentence brings in the scope of this control
>     plane framework (and this is even not necessarily true when vcat is
>     provided over different line cards):
>
>     "Note that this inverse multiplexing process can be significantly
>     easier to implement with SONET/SDH signals rather than packets."


Note that the "inverse multiplexing" in this context was used instead of
the then not-yet-standardized VCAT.  This is simpler than doing inverse
multiplexing with packets, because the timing and in-order delivery
of frames is more easily ensured with SDH/SONET signals than it is
with packets (where more sophisticated techniques are needed).

Also, not sure if the reviewer had a different setup in mind, but
component connections of a given VCAT group must terminate on the same
interface.

(As an aside, the signaling framework needs to have hooks for supporting
VCAT.  In particular, multiple VCAT groups can terminate on the same
interface, hence we need be able to tell them apart.  This is even more
important when LCAS capabilities are included since one would want to use
GMPLS signaling to setup and tear down individual "component
connections" of a VCAT group.)


> Section 6.3:
>
> 7. "However, if only standard concatenation is supported then reporting
>     gets trickier since there are constraints on where the STS-1s can be
>     placed. SDH has still more options and constraints, hence it is not
>     yet clear which is the best way to advertise bandwidth resource
>     availability/usage in SONET/SDH. At present, the GMPLS routing
>     protocol extensions define minimum and maximum values for available
>     bandwidth, which allows a remote node to make some deductions about
>     the amount of capacity available at a remote link and the types of
>     signals it can accommodate. However, due to the multiplexed nature
>     of the signals, the authors are of the opinion that reporting of
>     bandwidth particular to signal types rather than as a single
>     aggregate bit rate is probably very desirable."
>
>     -> the authors do not explain from which perspective and the reasons
>     this particular bw accounting report is desirable (sections 2.4.3 &
>     2.4.8 of GMPLS routing explains how these values are used to take
>     into account the multiplexing capability of a SONET/SDH interface),
>     there is no real determination of the missing information at remote
>     nodes for the establishment of an LSP with a certain amount of bw
>     (note that it is not an issue of flexible vs standard concatenation
>     issue but a control plane issue)


This is explained in detail in other sources that would be the
more appropriate references here. So we will provide a reference to
ITU-T documentation (G.7715.1, which outlines this as one of the
requirements)and
to "Optical Network Control, Chapter 12," which provides
an example that underscores reasons why such bandwidth accounting is
desirable.



> Section 7.3:
>
> 8. "This information is specified in three parts [17], each of which
>     refers to a different network layer."
>
> The description of the signaling elements shall mention the following:
> (section 7.3 refers to [17] but the latter does not correspond to the
> description given in this section)
>
>   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
>      which contains three parts: LSP Encoding Type, Switching Type, G-PID
>
>   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as SENDER_TSPEC/FLOWSPEC
>      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT, Transparency,
>      Profile
>
>   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
>
>   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473])

As of the last revision of this document, these were still being worked
out, so the draft spoke about these in generic terms. We will now refer
to the SDH/SONET encoding document, explain that the above parameters
are required, and expand on the use of each a bit, similar to how
it is there in the current text.

>
>
> Editorial:
> ----------
>
> Section 3:
>
> 1. Sometimes this document refers to GMPLS other to MPLS and
>     sometimes as above as "extending IP technology"


The usage of these terms was generally made in the context of how
things were being explained. We will try to uniformize the terms,
and refer consistently to "extending IP/MPLS technology", since both
have been extended for TDM and optical networks.

> Section 3.1
>
> 2. "When a packet reaches a core packet LSR, this LSR uses the label as
>     an index into a forwarding table to determine the next hop and the
>     corresponding outgoing label (and, possibly, the QoS treatment to be
>     given to the packet), writes the new label into the packet, and
>     forwards the packet to the next hop. "
>
> -> replace "core packet LSR" by "packet LSR"

Noted, will do in the revised version.

> Section 3.2:
>
> 3. "SDH and SONET are two TDM standards widely used by operators to
>     transport and multiplex different tributary signals over optical
>     links, thus creating a multiplexing structure, which we call the
>     SDH/SONET multiplex. SDH, which was developed by the ETSI and later
>     standardized by the ITU-T [4], is now used worldwide, while SONET,
>     which was standardized by the ANSI [5], is mainly used in the US.
>     However, these two standards have several similarities, and to some
>     extent SONET can be viewed as a subset of SDH. Internetworking
>     between the two is possible using gateways.
>
>     Should be rather as "ITU-T SDH (G.707) includes both the European
>     ETSI SDH hierarchy and the USA ANSI SONET hierarchy (T1.105)." [...]
>     "The ETSI SDH and SONET standards regarding frame structures and
>     higher order multiplexing are the same. There are some regional
>     differences on the terminology, on the use of some overhead bytes,
>     and lower order multiplexing. Interworking between the two lower
>     order hierarchies is possible using gateways."


Thanks for the new wording! We will make the change as suggested.

> Section 3.2
>
> 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes)
>     indicates the beginning of the VC/SPE in the payload of the overall
>     STM/SDH frame."
>
> -> replace "STM/SDH frame" by "STM/STS frame"

Thanks, will make the change.

> Section 4.1
>
> 5. "The SONET case is a bit difficult to explain since, unlike in SDH,
>     SPEs in SONET do not have individual names." they are simply referred
>     to as VT-N SPE

We will remove this sentence and instead use the term VT-N SPE,
where needed.

> Section 6:
>
> 6. Since this document distinguishes between "optical networks", TDM,
>     and WDM it would advisable to avoid the "optical TDM" as mentioned
>     in the below sentence (it has another meaning than MSn/RSn switching)

The specific sentence referred to is missing, but we think it's the
one in Section 8 (Conclusions).
"Finally, we reviewed  the signaling elements involved when setting up an
optical TDM
 circuit, ..."

We will remove the word "optical" for clarity.

> Section 6.1:
>
> 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE

Great, thanks for the catch! We will insert that in the second col.

>  > Section 6.1:
>
> 8. "Standard and flexible concatenations are network services, while
>     virtual concatenation is a SONET/SDH end-system service recently
>     approved by the committee T1 of ANSI and ITU-T." remove "recently
>     approved by the committee T1 of ANSI and ITU-T." and add the corr.
>     reference.

Sure, we will add appropriate reference.

> 9. "In one example of virtual concatenation, two end systems supporting
>     this feature could essentially "inverse multiplex" two STS-1s into a
>     virtual STS-2c for the efficient transport of 100 Mbps
> Ethernet traffic."
>
> -> STS-1-2v instead of "virtual STS-2c"

Great, will make the change.

> 10. "Section layer: Preserves all section overhead, Basically does not
>      touch any of the SONET/SDH bits."
>
> -> replace last part by "Basically does not modify or terminate
>     any of the SONET/SDH overhead bits"

Thanks, this is much clearer. We will reword.

>     left column of the table misses the SDH overhead equivalent

<Not sure which table this is referring to. There are only two
in the draft, that I don't see where the overhead is?>

> 11. Multiplexing of (?) in the following sentence "To perform
>      multiplexing, a SONET network element should be line terminating."

Thanks. We will reword as "To perform pipe multiplexing (i.e., multiplexing
of
50 Mbps or 150 Mbps chunks)".

<Guys, is this the right terminology.>

> Section 6.2:
>
> 12. In the following "Standardized SONET line level protection techniques
>      include: Linear 1+1 and linear 1:N automatic protection switching
>      (APS) and both two-fiber and four-fiber bi-directional line switched
>      rings (BLSRs). At the path layer, SONET offers uni-directional path
>      switched ring protection." the same applies to SDH (to be adapted
>      using the corr. terminology)

We will add a corresponding paragraph for SDH.


> Section 7:
>
> 13. "This VC-4 LSP can, in fact, be established between two non-
>      adjacent internal nodes in an SDH network, and later
>      advertised by a routing protocol as a new (virtual) link
>      called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as
>      reference

Sure, will add reference to the hierarchy document.

> 14. The following paragraph
>      "For instance, the payload of an SDH STM-1 frame does not fully
>       contain a complete unit of user data. In fact, the user data is
>       contained in a virtual container (VC) that is allowed to float over
>       two contiguous frames for synchronization purposes. A pointer in the
>       Section Overhead (SOH) indicates the beginning of the VC in the
>       payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3

Thanks, we will fix the text.