[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed text for the concatenation
Hi Stephen,
Within the e-mail of Eric it is clearly mentioned:
> Please send me your technical comments about the technical correctness of
> this text only. Please, delay discussions about the usefulness of these
> features and the way to implement them to another time. What is important is
> that each feature works. Your profile, implementation, or configuration
> should determine what you like and what you want to support, not this
> signalling.
I don't think you meet the Eric's wishes here... you should take the
last sentence as the real purpose of this proposed text. I think that
Eric would like to know if the technical description he gives on
contiguous concatenation is technically correct.
FYI: Standard virtual concatenation is part of the NVC field (i.e. not
determined by the CCT field). So GMPLS for SDH/Sonet includes standard
virtual concatenation.
Hope this helps you to understand a little bit more the purpose of the
Eric's e-mail.
Kind regards,
Dimitri.
Stephen Trowbridge wrote:
>
> Eric,
> I think this goes against earlier email that says T1X1 and ITU-T
> are responsible for specification of SONET/SDH. There are two
> standardized forms of concatenation. Your proposal includes only
> one of the standardized forms and two that are, for the moment,
> proprietary. If we accept that SONET/SDH is the responsibility
> of T1X1/ITU-T, then for the moment I think the options can only
> be:
> - No concatenation
> - Standard Contiguous concatenation
> - Standard Virtual concatenation
> - (all others are, for the moment proprietary) vendor specific
> concatenation types
> The other concatenation proposals must go to T1X1/ITU-T before
> they can be considered standardized.
> Regards,
> Steve Trowbridge
>
> "Mannie, Eric" wrote:
> >
> > Dear All,
> >
> > I am pleased to see so many people discussing so much on these mailing
> > lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > would like to make some progress.
> >
> > Please, carefully read the following text that clarifies the contiguous
> > concatenation part of the draft and that introduces one simple new
> > concatenation type.
> >
> > "This field indicates the type of SONET/SDH contiguous concatenation to
> > apply on the Elementary Signal. It is set to zero to indicate that no
> > contiguous concatenation is requested (default value). The values are
> > defined in the following table:
> >
> > Bits Contiguous Concatenation Type
> > ----- ----------------------------------
> > 000 No contiguous concatenation requested
> > 001 Standard contiguous concatenation
> > 010 Arbitrary contiguous concatenation
> > 011 Flexible arbitrary contiguous concatenation
> > others Vendor specific concatenation types
> >
> > Standard contiguous concatenation refers to the contiguous concatenation as
> > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> > concatenation relaxes the limitations of these standards in terms of the
> > location where a contiguous signal can start, and in terms of the number of
> > concatenated VC's/SPE's that can compose this signal.
> >
> > Flexible arbitrary contiguous concatenation is an optimisation of the
> > arbitrary contiguous concatenation that allows to "inverse multiplex" a
> > contiguously concatenated signal on a per multiplex section/line basis. In
> > order to be effectively used, an upstream node must indicate that its
> > supports this feature to its immediate downstream node, using the CCT field.
> > The downstream node can in that case use that feature and return a list of
> > labels, one for each element of the "inverse multiplex"; instead of one
> > single label indicating the beginning of the contiguous signal.
> >
> > The three types of contiguous concatenation defined here before defines
> > indeed a hierarchy of flexibility in the contiguous concatenation. If
> > selected, the flexible arbitrary contiguous concatenation, indicates that
> > any of the three types of contiguous concatenation can be chosen by the
> > downstream node. It is up to the downstream node to choose the one that it
> > wants to use. The upstream node, when receiving the labels from the
> > downstream node, may accept or refuse what was proposed."
> >
> > Please send me your technical comments about the technical correctness of
> > this text only. Please, delay discussions about the usefulness of these
> > features and the way to implement them to another time. What is important is
> > that each feature works. Your profile, implementation, or configuration
> > should determine what you like and what you want to support, not this
> > signalling.
> >
> > Take your time to read the text and to answer, it is 10PM in my time zone
> > and I will leave my office. I'll be back on Monday morning to read your
> > answers.
> >
> > Many thanks to all of you and have a nice week-end.
> >
> > Kind regards,
> >
> > Eric
> >
> > Eric Mannie
> > Technology & Standards Strategy Manager
> > Network Engineering Strategy
> > EBONE
> >
> > Terhulpsesteenweg 6A
> > 1560 Hoeilaart - Belgium
> >
> > Tel: +32 2 658 56 52
> > Mobile: +32 496 58 56 52
> > Fax: +32 2 658 51 18
> > E-mail: eric.mannie@ebone.com
> >
> >
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 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