AW: Moving right along ...

["Juergen Heiles" <[e-mail]>]

Hi Eric,

sorry for the delayed answer, but I have problems with the remtoe LAN access
here in Geneva.
I am therefore sending the mail via my ITU e-mail account and hope it is
accepted by the ccamp list server.

You compare groups with the multiplier, this is wrong. The multiplier sets
up n indivudal VC-n connections. The transport plane sees only the
individual VCs and the VC type (VC-4/372712711) is explicitly defined. So no
additional support at the transport plane is needed. It is a pure control
plane feature.
Groups are not a pure control plane feature. When you setup a group (AUG,
TUG, VTG, STSG) the transport plane still has to handle the individual
VCs/SPEs that are part of the group. Due the independent timing of each
VC/STS-SPE pointer processing has to be done per individual VC/SPE. The
transport plane cannot switch the group as a whole between STM/STS ports.
The transport plane therefore has to automatically detect the structure of
the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 or a
mixture and that may change over the lifetime of the group. This automatic
detection is not a standard SONET/SDH feature. As I described in previous
e-mails it is possible to do it based on pointer values during non error
situations. During errors (defects, AIS condtions) of individual singals of
a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. If a single
VC-12 in a TUG3 group has AIS (note that the AIS could result from a failure
outside the LSP), I assume that still all the other VCs of the group shall
be connected without errors. No SONET/SDH standard covers the automatic
detection.
So in my view it is similarly to transparency of individual SOH bytes. G.707
defines the individual SOH bytes, however transparency it is not standard
SONET/SDH and is therefore in the non-standard document. In the same way
G.707 defines groups, but not the automatic detection of the group
structure. So it should be moved to the non-standards document. At the
London meeting Kireeti said the decision on standard/non-standard features
is not based on rough consensus, but on what is in the ITU/ANSI documents.
Can you present me any ITU/ANSI standard that defines automatic detection of
the group structure?

You say groups are cool, may be for some applications. But note that groups
have the same fragementation problem as contiguous concatenation. The VCs in
a group always have to stay together. If for a example a TUG2 consits of 3
VC-12 you cannot put them in arbitrary free time slots. They have stay in
the time slots that belong to a single TUG2.


Concering the lable, aligning the SONET labels with the SDH lables makes
live easier. It is also a sign that SONET and SDH are identical for most
parts. I also showed you that SONET uses the same two-stage interleaving
process as SDH. If you look at the attached figure from T1.105 you see that
the STS-1 time slots in an STS-N signal are not continously number. First 3
STS-1s are combiend to a STS3 groupg and then the STS3 groups are
multiplexed. The same as SDH with AU3s and AUGs.
As the SONET lables will become the same as the SDH labels we don't have to
evaluate much. I already made a proposal some time ago. Why introduce
different labels without a need?
You haven't provided a reason for different lables. We had several people
that wanted to have the same label structure and only you opposed. So what
is rough consensus?

See my proposal for the labels below.


Juergen


This is my proposal for the label:
   The format of the label for SDH and/or SONET TDM-LSR link is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               S               |   U   |   K   |   L   |   M   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For SDH, this is an extension of the numbering scheme defined in
   G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same
   signaling scheme is used in order to provide easy interworkign between
   SDH and SONET signaling. For the S field a STS-3 group,which
   corresponds with the SDH AUG-1 level is introduce. The U field indicates
   the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. The K
   field is not significant for SONET as it doesn't support structured
   STS-3c-SPEs and must be set to zero.

   Each letter indicates a possible branch number starting at the
   parent node in the multiplex structure. Branches are considered as
   numbered in increasing order, starting from the top of the
   multiplexing structure. The numbering starts at 1, zero is used to
   indicate a non-significant field.

   When a field is not significant in a particular context it MUST be
   set to zero when transmitted, and MUST be ignored when received.

   When hierarchical SDH/SONET LSPs are used, an LSP with a given
   bandwidth can be used to tunnel lower order LSPs.  The higher
   order SDH/SONET LSP behaves as a virtual link with a given
   bandwidth (e.g. VC-3), it may also be used as a Forwarding
   Adjacency. A lower order SDH/SONET LSP can be established through
   that higher order LSP. Since a label is local to a (virtual) link,
   the highest part of that label is non-significant and is set to
   zero.

   For instance, a VC-3 LSP can be advertised as a forwarding
   adjacency. In that case the labels allocated between the two ends
   of that LSP (i.e. for that "link") will have S, U and K set to
   zero, i.e., non-significant, while L and M will be used to
   indicate the signal allocated in that VC-3.

     1. S is the index of a particular AUG-1/STS-3 group. S=1->N
     indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
     multiplex. For example, S=1 indicates the first AUG-1/STS-3 group,
     and S=N indicates the last AUG-1/STS-3 group of this multiplex.
     S is not significant for STM-0/STS-1.

     2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3
     group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a
     AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, while U=2->4
     indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3
     group.

     3. K is only significant for SDH VC-4 and must be ignored for
     SONET and SDH HOVC-3. It indicates a specific branch of a VC-4.
     K=1 indicates that the VC-4 is not further subdivided and
     contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-
     4. K is not significant when the AUG-1 is divided into AU-3s
     (easy to read and test).

     4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.
     It is not significant for an unstructured VC-4 or VC-3/STS-1 SPE. L=1
     indicates that the TUG-3/VC-3/STS-1 SPE is not further
     subdivided and contains a VC-3/C-3 in SDH or the equivalent in
     SONET. L=2->8 indicates a specific TUG-2/VT Group inside the
     corresponding higher order signal.

     5. M indicates a specific branch of a TUG-2/VT Group. It is not
     significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE.
     M=1 indicates that the TUG-2/VT Group is not further subdivided
     and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3
     inside the corresponding VT Group, these values MUST NOT be used
     for SDH since there is no equivalent of VT-3 with SDH. M=4->6
     indicates a specific VC-12/VT-2 SPE inside the corresponding
     TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE
     inside the corresponding TUG-2/VT Group. Note that M=0 denotes
     an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).


      The M encoding is summarized in the following table:

          M    SDH                          SONET
         ----------------------------------------------------------
          0    unstructured VC-4/VC-3  unstructured STS-1 SPE
          1    VC-2                    VT-6
          2    -                       1st VT-3
          3    -                       2nd VT-3
          4    1st VC-12               1st VT-2
          5    2nd VC-12               2nd VT-2
          6    3rd VC-12               3rd VT-2
          7    1st VC-11               1st VT-1.5
          8    2nd VC-11               2nd VT-1.5
          9    3rd VC-11               3rd VT-1.5
          10   4th VC-11               4th VT-1.5

   In case of contiguous concatenation, the label that is used is the
   lowest label of the contiguously concatenated signal as explained
   before. The higher part of the label indicates where the signal
   starts and the lowest part is not significant. For instance, when
   requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0.

   Examples of labels:

   Example 1: S>0, U=1, K=1, L=0, M=0
   Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group.

   Example 2: S>0, U=1, K>1, L=1, M=0
   Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.

   Example 3: S>0, U>1, K=0, L=0, M=0
   Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.

   Example 4: S>0, U>1, K=0, L>1, M=1
   Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1
SPE of the Sth AUG-1/STS-3 group.

   Example 5: S>0, U>1, K=0, L>1, M=9
   Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth
VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.

   Example 6: S>0, U=1, K>1, L>1, M=5
   Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of
the Sth AUG-1.




> -----Ursprüngliche Nachricht-----
> Von: Mannie, Eric [mailto:[e-mail]]
> Gesendet: Donnerstag, 18. Oktober 2001 18:58
> An: 'Heiles Juergen'; 'Kireeti Kompella'; [e-mail]
> Betreff: RE: Moving right along ...
>
>
> Hello Juergen,
>
> Your comments are addressed hereafter. Note that you didn't raised any
> technical problem or mistake in your comments (i.e. the draft "works" very
> well as it is).
>
> - the first comment is not about a technical issue but an
> "editorial" issue.
> - the second comment is about a change that will not bring any new
> capability.
>
> >Concerning the SDH/Sonet documents I want to raise a formal issue.
> >We have now two documents, a document that covers ITU/ANSI standard
> features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that
> covers non-standard features
> (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in
> Appendix 1
> of the standard feature document a non standard feature (Group signals) is
> listed. It is even mentioned that the use of groups (AUG, STSG,
> ...) is not
> described in standards. So this feature should be moved to the
> non-standards
> document. Otherwise the split of the documents doesn't make sense.
>
> We spend a considerable amount of time speaking about this
> particular issue
> and I still don't see any technical justification for what you said.
>
> For those who are not SDH/SONET experts some quick explanation:
>
> We call a "super-circuit" a set of physical circuits in the
> transport plane
> all belonging to the same LSP in the signaling plane. We defined two kinds
> of super-circuits: "group circuits" and "multiplicative circuits".
>
> Multiplicative circuits are setup using the multiplier field that
> we defined
> (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no
> objection
> about these ones.
>
> Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG,
> TUG, VTG (we defined the equivalent signal type in the signaling). The
> comment of Juergen is about these group circuits. A group circuit
> represents
> some bandwidth at a given place in the SDH/SONET multiplex. The
> advantage of
> such a super-circuit is that the customer can re-structure its content as
> he/she likes. The operator doesn't care.
>
> Such an application is possible and is already implemented. SDH/SONET is
> self-describing, i.e. by looking at the signal one can understand
> how it is
> structured (like Juergen explained on the mailing list), so one
> can setup a
> circuit without describing the content (very very cool).
>
> The transport plane ignores that the signaling plane uses an "abstraction"
> (i.e. an LSP) representing several physical circuits. Note that
> restoration
> and management belong respectively to the signaling plane and to the
> management plane in the IETF view (not to the transport plane like in the
> ITU-T view).
>
> From that point of view, group circuits are a GMPLS signaling
> plane feature
> and not a transport plane feature. We put the comment on the fact
> that this
> is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy.
>
> I could say clearly at the beginning of the draft that the signal
> types that
> we are defining in this document are not ITU-T signal types but
> GMPLS signal
> types (of course) whose have in some cases a direct relationship with the
> ITU-T signal types.
>
> Any objection ?
>
> >For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I
> prefer to have the same coding for Sonet and SDH. That makes the
> implementation for Sonet and SDH simpler. Furthermore ITU and T1
> have tried
> over the last years to align Sonet and SDH as much as possible. The
> definition of different labels for Sonet and SDH contradicts these
> activities.
>
> We discussed this one since a long time as well. Let me be clear:
>
> - labels are local to an interface (we all agree).
> - a link (interface) is operated at one point in the time as either SDH or
> SONET.
> - your proposal will require to re-evaluate many things.
> - and it took us a lot of time to fine-tune and to validate the current
> label structure.
> - we could have technical issues with your proposal that would impact more
> than this draft (Dimitri saw some of them, please see with him).
> - you never provided a complete analysis of your proposal.
>
> But more important: your proposal doesn't bring any additional
> functionality
> to the draft.
>
> At this very late stage, since this not bringing any new
> functionality, and
> since the label structure is very stable since a long time, I would prefer
> not to restart a long technical discussion to change and re-validate the
> draft.
>
> Kind regards,
>
> Eric
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Kireeti Kompella [mailto:[e-mail]]
> > Gesendet: Mittwoch, 17. Oktober 2001 11:25
> > An: [e-mail]
> > Betreff: Moving right along ...
> >
> >
> > Despite the energetic subject line, we the WG chairs have been
> > lax in our duties.  So, here goes:
> >
> > Lou has submitted the latest versions of the generalized
> > signaling documents quite some time ago (thanks, Lou):
> >
> > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > draft-ietf-mpls-generalized-signaling-06.txt
> >
> > Also, Eric has posted the SONET/SDH documents (merci, Eric):
> >
> > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> >
> > All of these should have addressed the issues raised in the earlier
> > versions.  Please read the new versions, and send your comments to
> > the list by Tuesday Oct 23.  At that point, when the final round
> > of comments have been addressed, these docs will go to IESG Last
> > Call.  If any one objects to sending these docs to IESG Last Call,
> > raise your issues now.
> >
> > I see that the GMPLS architecture document is a CCAMP WG doc, but
> > the minutes say that we should look for consensus on the list.  So,
> > if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > arrived at a consensus, remind me :-))  If nothing is heard, the doc
> > will progress to WG Last Call.
> >
> > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> > CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > list know what your thinking is on these.  (BTW, both these docs
> > were to have some edits done.  If the authors could do that before
> > the next IETF, we can try to make more progress then.)
> >
> > The MIB overview doc was recently posted.  Please read and comment
> > to the list.
> >
> > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > was generally thought to be useful; it will be published as a
> > CCAMP informational doc.  This begins a two week Last Call on
> > the doc, ending Tuesday Oct 30.
> >
> > There was no consensus on whether the GMPLS framework should be
> > a CCAMP WG doc.  Please indicate your pleasure.
> >
> > draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > raised that this draft is close to ready for WG Last Call.  Please
> > review it, and let us know if you disagree.
> >
> > The OLI requirements doc was broadly accepted.  Please let the
> > list know if you think this doc should be a WG doc.
> >
> > It's still open whether we (the IETF) should be working on
> > LMP-WDM.  I urge the authors to keep on working on the doc, and
> > keeping it in sync with LMP; however, we will postpone making it
> > a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > happen in Salt Lake City.
> >
> > There was reasonable interest in the tunnel trace requirements
> > doc.  Let's formalize this: do you think this should be made a
> > CCAMP WG document?
> >
> > Summary:
> >
> > 1) Final comments and IESG Last Call readiness for:
> > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > draft-ietf-mpls-generalized-signaling-06.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> >
> > 2) Should the following documents be CCAMP WG docs?
> > draft-bonica-tunneltrace-02.txt
> > draft-fontana-ccamp-gmpls-g709-00.txt
> > draft-ietf-ccamp-gmpls-architecture-00.txt
> > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > draft-many-ccamp-gmpls-framework-00.txt
> > draft-many-oli-reqts-00.txt
> >
> > 3) Comment on MIB overview.
> >
> > 4) Two week Last Call comments on
> > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> >
> > 5) Last Call readiness of
> > draft-ietf-ccamp-gmpls-architecture-00.txt
> > draft-ietf-ccamp-lmp-01.txt
> >
> > Thanks,
> > Kireeti.
> >
>