Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt

[Maarten Vissers <mvissers@lucent.com>]

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:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard