[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt
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