[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt
Deborah, all,
The "label" format issue is orthogonal to the discussion we
are engaging with this I-D. Nevertheless we have already
received numerous comments and lengthy discuss this issue;
therefore i think the decision will be endorsed during the
next IETF meeting (... from the control plane viewpoint) but
this orthogonality implies that different LSP Encoding Type
for SDH and Sonet do not preclude "same" or better "equivalent"
SUKLM label notation. So please do not take this I-D in this
context.
Now, you (Maarten as well by the way) are arguing since a long
time now to merge the two corresponding SDH and SONET LSP
Encoding Type codepoints into a single unique SDH/Sonet value.
This is an different issue. My point of view on this issue has
always been the same if the transmission plane defines inter-
working between both "encoding" without any explicit processing
coming from control plane then your proposal can be considered.
This would result in merging of the SDH and SONET codepoints
into a G.707 codepoint for instance for the LSP Encoding Type.
Nevertheless it seems that when comparing your statement (as
well as the conclusion of Maarten) and the differences listed
it looks like there is a contradiction: if differences may
appear between ETSI SDH interfaces themselves these differences
can't be fewer when including ANSI SONET interfaces within
the same set. I am not saying these differences are significative
for the control plane (Maarten describes them as "noise") but i
would like to open the discussion and clearly determine if they
are impacting the control plane specification and corresponding
processing - and to which extend of course: if we define a common
value and then plenty of exceptions what's the advantage ? -
This is one of the objective of the document, it is not at all
the aim to "redefine" the interworking section 6.4 of G.707. Your
point of view seems to be very clear: abstract these differences...
we will see in our future discussions if this can be achieved
without any impact on the control plane definition. Remember
also that this I-D is informational.
Hope this clarifies a little bit the situation.
Regards,
- dimitri.
"Brungard, Deborah A, ALCTA" wrote:
>
> Just back from vacation, my comments may be late but they are not much
> different from my previous comments. It seems we are still discussing one
> label vs. two...
>
> I, and others, have continually commented that G.707 contains both ETSI SDH
> and ANSI SONET. It has always contained both. Supporting two gmpls general
> labels - one for ANSI T1.105 and one for ITU-T G.707 - is incorrect and adds
> unnecessary complexity for both equipment and operators. If by sdh, the
> implication is the TUG-3 structure, than refer to this explicitly in the
> label. Or say ETSI sdh. The preference by international operators is to
> simplify - we prefer one general label with technology specific details
> (TUG3 vs. TUG2) to be addressed by the technology specific documents. Other
> international operators have supported my comments on this exploder. If
> this comment is not acceptable by the editors of the mpls-gen signaling
> document, it would be productive to have a response as to why?
>
> If the draft on sonet-sdh-interwork is intended to be a rationale for
> maintaining two different labels, we can grueling go thru the exercise on
> this exploder and comment on it. I would propose (as Randy has already
> requested) for sdh/sonet technology discussions, let's take the discussion
> to the ITU-T exploder i.e. my first comment on this draft is the incorrect
> assumption that one needs to do transport level processing to interwork a
> VC-3 with a STS-1 SPE. This is incorrect - one does not touch the signal -
> no removal of fixed stuff bytes is required - the VC-3 and STS-1 SPE are
> equivalent for DS3 mappings and 34M (note the DS3 mapping is different than
> a 34M mapping). It is simply transporting a VC-3 containing a DS3 (or 34M)
> via AU3 or via AU4 (both supported in G.707!). If the authors of this
> document need additional info, just ask via the ITU-T Q11 exploder. Or we
> can discuss here...
>
> We can continue to go thru the draft line by line, or to move this
> discussion quickly, if we go to section 4, the only interworking rule which
> is listed as needed, is the conversion of the LSP encoding type from sdh to
> sonet. IF the same label would apply, there would be no need for gmpls
> sdh-sonet interworking.
>
> As Maarten notes below, there are many capabilities (positive
> connotation)/differences (negative connotation) within ETSI SDH and within
> ANSI SONET which do not allow for simply connecting two pieces of equipment
> either at a link level or end-to-end path level. A simple connection request
> may not even work between the same vendor's equipment :-( Defining different
> gmpls labels for sdh vs. sonet does not guarantee transport connectivity for
> SDH equipment or SONET equipment.
>
> Deborah Brungard
> AT&T
>
>
>
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Friday, November 23, 2001 4:49 AM
> To: Dimitri Papadimitriou
> Cc: ccamp; q14/15
> Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt
>
> Dimitri,
>
> These differences are not specifically between SDH and SONET, you will also
> find
> a number of those between SDH and SDH or between SONET and SONET.
> Furthermore
> there are many more items that may require negotiation between elements in
> the
> connection.
>
> If you look into the items you will notice that they are associated with the
> ports at the end of the connection or at intermediate points along the
> connection. As such a generic mechanism is required that establishes
> interworking for the case two ports (monitoring points) have different
> options
> selected.
>
> Port types to be considered (just a first quick list; still very
> incomplete):
>
> VC-m (m=11,12,2) port
> - Path Trace Identifier (J2): 16-byte and 64-byte path trace identifier
> strings
> - performance monitoring: BIP violation counting, Errored Block (EB)
> counting
>
> VC-m (m=11,12,2) SNC protected port
> - all kind of SNC protection related parameters; e.g. SNC protection type,
> operation type, holdoff timer, etc.
>
> VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) port
> - Path Trace Identifier (J1): 16-byte and 64-byte path trace identifier
> strings
> - Path Trace Identifier (J1): 64-byte path trace identifier formats
> - performance monitoring: BIP violation counting, Errored Block (EB)
> counting
> - user channel support: none/F2/F2F3/F3
>
> VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) TCM port
> - Tandem connection monitoring: option I and II
>
> VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) SNC protected port
> - all kind of SNC protection related parameters; e.g. SNC protection type,
> operation type, holdoff timer, etc.
>
> STM-N (N=0,1,4,16,64,256) RS port
> - Regenerator Section Trace Identifier (J0): 1-byte and 16-byte section
> trace
> identifier strings
> - RS-DCC support
> - RS orderwire support
> - RS user channel support
>
> STM-N MS port
> - older AU/STS pointer processors: ss-bits source processing: generation of
> "10" or "00" pattern, sink processing: verify presence of ss-bit pattern or
> ignore ss-bit pattern
> - newer AU/STS pointer processors: source generates ss-bits "10", sink
> ignores
> ss-bits ==> i.e. no interworking issue
> - Synchronisation Status Message (SSM) code set: option I, II or III (see
> G.781)
> - MS-REI: MS-REI supported/not-supported
> - STM-64 MS-REI: M0M1 or M1 only
> - MS-DCC support
> - RS orderwire support
>
> STM-N (N=0,1,4,16,64,256) MS protected port
> - K1K2 MSP-APS switching type codes (uni-/bi-directional) in K2[6-8] for
> case of
> 1:n
> - all kind of MS protection related parameters (see G.841 and G.783); e.g.
> switching type, operation type, architecture type, etc.
>
> STM-N (N=16,64,256) MS SPRing protected port
> - all kind of MS SPring protection related parameters
>
> In general, the setup of the connection may have more than one phase
> associated:
> 1) connection bearer setup
> 2) connection monitoring setup
> 3) connection protection setup
>
> The latter two phases require a detailed review of the MI_XXX parameters in
> the
> atomic functions in G.705, G.781, G.783, G.798 as well as a review of the
> set of
> atomic functions that represent normally optional functionality. Everything
> that
> allows selectivity on a per connection basis needs to be identified and
> allocated to connection monitoring and protection service signalling.
>
> As you can see the few specific SONET/SDH differences are like noise and
> don't
> deserve separate LSP encoding types. Different LSP encoding types will
> complicate things more than help.
>
> Regards,
>
> Maarten
>
> Dimitri Papadimitriou wrote:
> >
> > Hi Maarten,
> >
> > Thanks for these comments, it has been left for further consideration
> > within this document, but you know that they are "differences" between
> > Sonet and SDH OH in particular at the POH: J1/J2, B3, G3/K4 others are
> > mainly J0 at RS/SOH and K2 MS/LOH.
> >
> > Nevertheless, the key question is does it impact the control plane
> > specification ? And this is one of the purpose of this document (again
> > at a first stage).
> >
> > So, prior to propose a merge of the control plane code-points i would
> > like first to ask you if the current proposals made in order to provide
> > interoperability have been accepted and integrated. Knowing that we can
> > then evaluate the impact on the control plane and after we could
> > consider
> > your proposal.
> >
> > Many thanks,
> > - dimitri.
> >
> > Maarten Vissers wrote:
> > >
> > > All,
> > >
> > > I had a look on contribution
> > > "draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt" and would like to
> provide
> > > some comment.
> > >
> > > 1) I "liked" :-( the first sentence in section 2: "This section
> describes how
> > > SDH and SONET can interwork at the transport plane level." I only
> thought that
> > > this was already defined for many years in G.707. :-)
> > > A reference to section 6.4/G.707 seems more appropriate, as it will show
> > > interconnection in general between VC-3 transport in multiplex sections
> (AU-3,
> > > STS-1) and VC-4 paths (TU-3).
> > > It will also show interconnection between VC-11 transport in VC-11 link
> > > connections (TU-11, VT1.5) and VC-12 link connections (TU-12).
> > >
> > > 2) From a connection management perspective (scope of the control
> plane), the
> > > STS-1, Higher Order VC-3 and Lower Order VC-3 can be treated as one
> signal type.
> > > Interworking happens simply within the VC-3 layer network by means of
> connecting
> > > a (HO)VC-3/STS-1/(LO)VC-3 SNP with another (HO)VC-3/STS-1/(LO)VC-3 SNP.
> > > It is unimportant how the VC-3/STS-1 arrives/departs at/from the
> VC-3/STS-1 SNP;
> > > i.e. it could be within a STM-N/OC-N multiplex section, VC-4, E4 or E3.
> > >
> > > Links (link bundles) which support VC-3/STS-1 link connections will
> simply
> > > advertise this capability via their LSAs. A VC-3 fabric having two VC-3
> > > supporting links (link bundles) can "blindly" connect a VC-3/STS-1 SNP
> within
> > > the first link to a VC-3/STS-1 SNP within the second link.
> > >
> > > 3) SONET/SDH interworking GMPLS gateway function seems only necessary
> due to the
> > > fact that two LSP Encoding Types were allocated. If just one LSP
> Encoding Type
> > > would be allocated for both SDH and SONET, we would not require any
> GMPLS
> > > SDH-SONET interworking functionality.
> > >
> > > Therefore my proposal to merge SDH and SONET LSP Encoding types into one
> > > codepoint referred to as SDH/SONET.
> > >
> > > Regards,
> > >
> > > Maarten
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard