Subject: I-D ACTION:draft-riegel-pwe3-tdm-requirements-01.txt

From: [email-masked]
Date: Fri, 20 Dec 2002 07:08:28 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Requirements for Edge-to-Edge Emulation of TDM 
                          Circuits over Packet Switching Networks (PSN)
	Author(s)	: M. Riegel
	Filename	: draft-riegel-pwe3-tdm-requirements-01.txt
	Pages		: 26
	Date		: 2002-12-18
	
This document specifies the particular requirements for
edge-to-edge-emulation of circuits carrying time division multiplexed
digital signals of the PDH as well as the SONET/SDH hierarchy over
packet-switched networks.  It is based on the common architecture for
Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH].
It makes references to requirements in [PWE3-REQ] where applicable
and complements [PWE3-REQ] by defining requirements originating from
specifics of TDM circuits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-riegel-pwe3-tdm-requirements-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-riegel-pwe3-tdm-requirements-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-riegel-pwe3-tdm-requirements-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "tom k. johnson" <[email-masked]>
Date: Fri, 20 Dec 2002 08:02:37 -0500

Max - 

Nice job!  

I have a few minor comments that I'll 
pass along to you off-list, but I would 
like to think this is ready to be 
adopted by the WG.

(Danny?)

-Tom

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 20, 2002 7:08 AM
> Cc: [email-masked]
> Subject: [PWE3] I-D ACTION:draft-riegel-pwe3-tdm-requirements-01.txt
> 
> 
> 	"FILE 
> /internet-drafts/draft-riegel-pwe3-tdm-requirements-01.txt".
>

---

From: Danny McPherson <[email-masked]>
Date: Fri, 20 Dec 2002 09:51:30 -0700

We were indeed hoping to make it a WG item, any objections to 
doing so with the next revision?

-danny

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 22 Dec 2002 14:55:00 +0200

>    The term "TDM" will be used in this documents as general descriptor
>    of the synchronous bit streams according to the Plesiosynchronous
>    Digital Hierarchy (PDH) used in telephony networks.
> 
> That would be the *Plesiochronous* Digital Hierarchy, yes?
> which, by definition, does not use solely synchronous bitstreams?
> which aren't necessarily TDM, either?

I had a similar comment, i.e. that it would be better not to define TDM
through PDH. HOWEVER, the terminology is technically correct as it stands.

The Plesiosynchronous Digital Hierarchy is just that - 
a hierarchy of rates, the lowest of which are E1 and T1
which are, of course, not PDH signals themselves.
The idea is that a hierarchy of PDH signals is based
on one of two basic synchronous signals.
The hierarchy is considered to include the basic building block
and the composite signals.

> I'm a bit worried that this IETF wg hasn't really gotten a handle on
> PDH requirements, because all the PDH experts are elsewhere. This is
> really a SONET/SDH description document. Not that I know a lot about
> PDH myself...

Actually, the document started out as a pure E1/T1/E3/T3 document,
and only in this latest revision was SONET/SDH added.
I think we have a few people who understand PDH quite well here.

> Not sure what correct consideration of plesiochronous would do for
> e.g. clock recovery. but playing fast and loose with e.g.
> interchangeable circuit/bitstream terms isn't doing much for my
> comfort zone either.

Up to now we have considered the precise mechanisms
for clock recovery as implementation-specific,
and not in scope.

> Would suggest the term "raw" to "unstructured" - could be that it's
> structured, but that the PW just doesn't recognise the structure,
> while later PWs (more applicability statements) might well treat it as
> structured because they recognise it. But any structured (recognised)
> stream could conceivably be carried as a raw stream (with a
> performance hit, presumably - and then handled via
> out-of-scope-for-us NSP?); the reverse is not true.

The idea was "unstructured" from the transport point of view. 
I discussed our use of the term in my explanatory talk in Atlanta.
I personally also like "raw", but people are used to the term "unstructured"
for raw bit streams at the PDH rates.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 22 Dec 2002 18:54:46 +0200

Lloyd, Yaakov, Max and all,
Please see several comments inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Sunday, December 22, 2002 2:55 PM
> To: Lloyd Wood
> Cc: [email-masked]
> Subject: RE: [PWE3] I-D 
> ACTION:draft-riegel-pwe3-tdm-requirements-01.txt 
> 
> 
Absolutely. Lloyd, thank you for the correction.
> > which, by definition, does not use solely synchronous bitstreams?
Regarding the term "synchronous" - personally I think that the term 
"constant rate bits stream(s)" would be more appropriate than 
"synchronous bit stream(s)" in the context of this document. Among other
things
 - because "constant rate" is fully applicable to a single bit stream, while
"synchronous"
seems to suggest several streams with the same clock (at least to me).
> and the composite signals.
Yaakov, sorry to note - but please look at ITU-T G.705 "Characteristics 
of PLESIOCHRONOUS digital hierarchy (PDH) equipment functional blocks".
The P-word in question is present in the title of the standard, and, all
things being equal,
I tend to trust in the ITU-T spelling and meaning since I believe they have
defined 
the term (I doubt you can find it in the "Iliad" or "Odyssey"- but then my
knowledge 
of classics is limited) . In addition, G.705 also states (in Section 1
"Scope") that it
"encompasses all the requirements of G.704, G.742, G.743, G.747, G.751 and
G.752."
Hence I do not see any problem either with using the (correctly spelled)
P-word or with applying it to E1 and T1. 
> I think we have a few people who understand PDH quite well here.
I have reasons to believe that a few of the co-authors understand SONET/SDH 
quite well, too. 
> > interchangeable circuit/bitstream terms isn't doing much for my
My understanding is that the P-word (PDH) is used to describe a network
where nodes are interconnected over constant rate bit stream links with
clocks
that are not necessarily all locked to the same synchronization source. In
this
it differs from an SDH network where the clocks of all the links are
traceble
to the same synchronization source. 
Since any given PW emulates a single constant rate bit stream, and since
clock recovery - at least within the scope of this document - always
refers to individual PWs, I do not think that clock recovery is affected.
Howevevr, it would be good to get some additional input.
> for clock recovery as implementation-specific,
In fact this has been one of the points of no contention in the TDM
emulation work 
so far.
> for raw bit streams at the PDH rates.
I think that this is an important point that should be addressed in the
next revision(s) of the draft. One of the inputs could be the ATM-CES 
implementation agreement which discusses structured and unstructured 
EMULATION and provides (within its scope) applicability statements for each.

---

From: "Ron Cohen" <[email-masked]>
Date: Sun, 22 Dec 2002 22:25:24 +0200

Max

1. VC-13 is a typo. Please change VC-13 to:

- In section 5.3 the two last bullets should read:
   
 SONET VT-N (N = 1.5, 2, 3, 6) / SDH VC-11, VC-12, VC-2
 
 SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3   

2. Synchronization Network scenarios

Considering example 4.3.3 Adaptive Network Scenario, and 4.3.2 Relative
Network Scenario, I would change the drawing and the default explanation
to have one of the CEs work in loop timing. This is the common setup of
CEs, where one is the master and the other is the slave clock, and the
Plesiosynchronous mode is the rare case.

Thanks
Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, December 20, 2002 2:08 PM
> To: IETF-Announce:
> Cc: [email-masked]

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-riegel-pwe3-tdm-requirements-01.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 23 Dec 2002 07:58:20 +0200

> Absolutely. Lloyd, thank you for the correction.

Lloyd, 

I completely missed your first point the first time,
not even having noticed the "syn" that slipped in.

My remarks referred only to your second comment

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 23 Dec 2002 08:00:23 +0200

> and some of them can even spell it?

It would be a syn to think no-one can,
although it might give you plesiure.

Y(J)S

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 23 Dec 2002 10:58:30 +0100

See inline for some comment...

> through PDH. HOWEVER, the terminology is technically correct as it stands.

PDH is one of the hierarchies that uses TDM. 
TDM is furthermore used in e.g. SDH/SONET and OTN.

> which are, of course, not PDH signals themselves.

E1 and T1 are PDH signals at level 1, and are presumably the most important
ones.

> and the composite signals.

G.702 provides the overview of the hierarchy.
http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-G.702

> I think we have a few people who understand PDH quite well here.

I would recommend to consult the experts in ITU-T SG15. The PWs will connect to
the existing networks specified and maintained by them, and essentially become a
part of that network.

> for clock recovery as implementation-specific,

Most important here is the jitter/wander requirements you have to meet. 
Those requirements must be included in the specification.
ITU-T Q.13/15 experts can help you with this.
Applicable are ITU-T Rec. G.823, G.824, G.825, ETSI EN 302 084.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 23 Dec 2002 11:49:34 +0100

Sasha,

> clocks that are not necessarily all locked to the same synchronization
> source. In this it differs from an SDH network where the clocks of all
> the links are traceble to the same synchronization source.

In PDH the signals (within one layer network) are plesiochronous with respect to
each other... they have the same nominal frequency but in addition are allowed
to have a small variation on top of it. See also the definition in Rec. G.701
http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-G.701

========== copied from G.701 =============

6014	isochronous
	F:  isochrone
	S:  isócrono
The essential characteristic of a time-scale or a signal such that the time
intervals between consecutive significant instants either have the same duration
or durations that are integral multiples of the shortest duration.
NOTE - In practice, variations in the time intervals are constrained within
specified limits.

6015	anisochronous
	F:  anisochrone
	S:  anisócrono
The essential characteristic of a time-scale or a signal such that the time
intervals between consecutive significant instants do not necessarily have the
same duration or durations that are integral multiples of the shortest duration.

6016	synchronous [mesochronous]
	F:  synchrone [mésochrone]
	S:  síncrono [mesócrono]
The essential characteristic of time-scales or signals such that their
corresponding significant instants occur at precisely the same average rate.
NOTE - The timing relationship between corresponding significant instants
usually varies between specified limits.
 
6017	homochronous
	F:  homochrone
	S:  homócrono
The essential characteristic of time-scales or signals such that their
corresponding significant instants have a constant, but uncontrolled, time
relationship with each other.

6018	non-synchronous [asynchronous/heterochronous]
	F:  non synchrone [asynchrone/hétérochrone]
	S:  no-síncrono [asíncrono/heterócrono]
The essential characteristic of time-scales or signals such that their
corresponding significant instants do not necessarily occur at the same average
rate.

6019	plesiochronous
	F:  plésiochrone
	S:  plesiócrono
The essential characteristic of time-scales or signals such that their
corresponding significant instants occur at nominally the same rate, any
variation in rate being constrained within specified limits.
NOTES
1	Two signals having the same nominal digit rate, but not stemming from the same
clock or homochronous clocks, are usually plesiochronous.
2	There is no limit to the time relationship between corresponding significant
instants.

6020	heterochronous
	F:  hétérochrone
	S:  heterócrono
The essential characteristic of time-scales or signals such that their
corresponding significant instants occur at different nominal rates.
NOTES
1	Two signals having different nominal digit rates, and not stemming from the
same clock or from homochronous clocks are usually heterochronous.
2	Terms 6014 to 6020 are based on the following Greek roots:
iso	=  equal
homo	=  same
plesio	=  near
hetero	=  different.

=========== end of copy from G.701 ================

When used in a switching of voice signals application, the frequency of the PDH
1544 and 2048 kbit/s signals are further constraint and must be synchronous to a
PRC (primary reference clock, G.811). Specific "synchronous frame structures"
have been defined for this purpose in G.704.

> Howevevr, it would be good to get some additional input.

The basic PW provides a connection over which a stream of bits is transparently
transported. This is similar to e.g. transporting a stream of bits over PDH,
SDH/SONET or OTN; e.g. 34 Mbit/s over SDH, STM-16 over OTN. To guarantee
interworking and the performance of a connection, jitter/wander, clock and PLL
bandwidth specifications have been developed. See e.g. 15.2/G.783 and G.8251.

> In fact this has been one of the points of no contention in the TDM

The precise mechanisms for clock recovery are implementation specific, but the
requirements that those implementations must meet must be standardised.

Regards,

Maarten

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 23 Dec 2002 13:13:50 +0200

Maarten and all,
Thank you for the clarification.
Please see also some responses inline.

With best regards,
                                   Sasha Vainshtein

> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, December 23, 2002 12:50 PM
> To: Sasha Vainshtein
> Cc: [email-masked]
> Subject: Re: [PWE3] I-D 
... snipped ...
> have been defined for this purpose in G.704.
My understanding (possibly limited) is that this imposes strict limitations
on n*DS0 emulation with its potential grooming or districguted cross-connect
applications.
> SDH/SONET or OTN; e.g. 34 Mbit/s over SDH, STM-16 over OTN. 
> To guarantee interworking and the performance of a connection, 
> jitter/wander, clock and PLL bandwidth specifications have been developed.
See e.g. 
> 15.2/G.783 and G.8251.
I think that this analogy is correct for unstructured TDM emulation.
Structured TDM
emulation seems to be somewhat different e.g., similar to bit-synchronous
mapping
of 1544 kbit/s into VC-11 and of 2048 kbit/s into VC-12. Is this correct?
> requirements that those implementations must meet must be 
I agree.

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 23 Dec 2002 19:02:41 +0200

Maarten and all,
Basically looks a very good good idea.
One point that bothers me, though: G.705 does not 
mention (or so it seems) any connection points for CAS.
I would like to understand (1) whether this is correct
and (2) what does this mean architecturally. 

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, December 23, 2002 3:33 PM
> To: [email-masked]
> Subject: Re: [PWE3] I-D 
> I would like to propose to extend the requirements document 
> with a more specific
> identification of the ingress/egress points of a PW. I.e. a 
> PW connects
> essentially two (ITU-T G.805) Connection Points (CP) within a 
> layer network.
> 
> E1 PW connects two P12x_CPs for case of transparent 
> (unstructured) service:
> 
>    P12x_CP      P12x Link Connection     P12x_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> E1 PW connects two P12s_CPs for case of transparent 
> frame-synchronous service:
> 
>    P12s_CP      P12s Link Connection     P12s_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> T1 PW connects two P11x_CPs for case of transparent 
> (unstructured) service:
> 
>    P11x_CP      P11x Link Connection     P11x_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> E3 PW connects two P31x_CPs for case of transparent service:
> 
>    P31x_CP      P31x Link Connection     P31x_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> T3 PW connects two P32x_CPs for case of transparent service:
> 
>    P32x_CP      P32x Link Connection     P32x_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> VC-n (n=11,12,2,3,4,4-4c,4-16c,4-64c) PW connects two Sn_CPs 
> for case of
> transparent service:
> 
>     Sn_CP        Sn Link Connection       Sn_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> ATM VP PW connects two VP_CPs for case of transparent service:
> 
>     VP_CP        VP Link Connection       VP_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> ATM VC PW connects two VC_CPs for case of transparent service:
> 
>     VC_CP        VC Link Connection       VC_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> DS0 PW connects two P0_CPs for case of transparent service:
> 
>     P0_CP       P0s Link Connection       P0_CP
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> The information transported is the Characteristic Information (CI). 
> E.g. over the VC-n CP and VC-n PW flows the VC-n CI.
> These CPs and CIs are explicitly defined in ETSI EN 300 
> 417-4-1, EN 400 417-5-1,
> Rec. G.705, G.783, I.732 and can as such be referred to from 
> the PWE3 RFCs.
> 
> P0_CI:   17/G.705
> P11x_CI: 15/EN 300 417-5-1
> P12x_CI: 14/EN 300 417-5-1
> P12s_CI: 7/EN 300 417-5-1 and 12/G.705
> P31x_CI: 12/EN 300 417-5-1
> P32x_CI: 11/EN 300 417-5-1
> P11x_CI: 15/EN 300 417-5-1
> Sn_CI:   4,5,6,7/EN 300 417-4-1, 5/EN 300 417-9-1 and 12,13/G.783
> VP_CI:   D.3/I.732
> VC_CI:   D.5/I.732
> 
> For the case a PW supports multiplexing, the PW is a Link 
> with multiple Link
> Connections.
> Example VC-n PW with 5x VC-n:
> 
>     Sn_CPs       Sn Link Connections      Sn_CPs
>  ---- O ----------------------------------- O -----
>  ---- O ----------------------------------- O -----
>  ---- O ----------------------------------- O -----
>  ---- O ----------------------------------- O -----
>  ---- O ----------------------------------- O -----
>         |<-------------PW---------------->|
> 
> 
> 
> 
> The PW connects via the CPs at its edge to atomic functions 
> defined in G.705,
> G.783, I.732, etc. This can be an adaptation function or a 
> connection function.
> Example: VC-4 PW with STM-1 and STM-4 interfaces and no 
> flexibility in STM-4
> interface
> 
>                                                       -----------
>                                                       --------- |
>                                                       ------- | |
>                                                             | | |
>                S4_CP                             S4_CP      | | |
>        ----------O------------              -------O------- | | |
>        |                     |              |             | | | |
>     MS1/S4_A                 ------ PW ------             MS4/S4_A
>        |                                                     |
>      MS1_TT                                                MS4_TT
>        |                                                     |
> 
> When there would be flexibility in the selection of the VC-4 
> in the STM-4
> interface, a VC-4 connection function (S4_C) is included and 
> connected to the
> VC-4 PW
> 
> 
>                                            -----------------------
>                                            |         S4_C        |
>                                            -----------------------
>                S4_CP                        |             | | | |
>        ----------O------------        S4_CP O      S4_CPs O O O O
>        |                     |              |             | | | |
>     MS1/S4_A                 ------ PW ------             MS4/S4_A
>        |                                                     |
>      MS1_TT                                                MS4_TT
>        |                                                     |
> 
> 
> The PW can be modelled as well with similar atomic 
> functions... in this example
> there would be a MPLS-VC/S4_A function at each edge of the PW 
> connected via a
> MPLS-VC trail...
> 
>                                            -----------------------
>                                            |         S4_C        |
>                                            -----------------------
>                S4_CP                        |             | | | |
>        ----------O------------        S4_CP O      S4_CPs O O O O
>        |                     |              |             | | | |
>     MS1/S4_A            MPLS-VC/S4_A   MPLS-VC/S4_A       MS4/S4_A
>        |                     |              |                |
>      MS1_TT              MPLS-VC_TT     MPLS-VC_TT         MS4_TT
>        |                     |              |                |
>                              ----------------
> 
> 
> For transparent (unstructured) E1 connection this model would be:
> 
>               P12x_CP                            P12x_CP
>        ----------O------------              --------O---------
>        |                     |              |                |
>    E12/P12x_A          MPLS-VC/P12x_A MPLS-VC/P12x_A      E12/P12x_A
>        |                     |              |                |
>      E12_TT              MPLS-VC_TT     MPLS-VC_TT         E12_TT
>        |                     |              |                |
>                              ----------------
> 
> Adding these network architecture models to the PWE3 
> architecture document,
> would connect existing specifications in ITU-T with the PWE3 
> specifications not
> leaving any ambiguity about the actual signals transported via a PW. 
> It also adds implicitly the interface specifications of the 
> interfaces that
> provide access to these PWs. Example: G.705 specifies how to 
> access the P12x_CP
> (via e.g. E12_TT and E12/P12x_A functions), while G.783 
> specifies access to this
> P12x_CP via OSn, RSn, MSn, S4 and finally S12_TT and 
> S12/P12x_A functions.
> 
> 
> 
> When the PW is able to multiplex multiple signals, the 
> MPLS-VC/Client_A function
> will have multiple Client_CPs. E.g. for case of PW capable to 
> multiplex 5 VC-12
> signals:
> 
>              | | | | | 
>              O O O O O S12_CPs
>              | | | | |
>            MPLS-VC/S12_A
>                  |
>              MPLS-VC_TT
>                  |
> 
> 
> Regards,
> 
> Maarten
>

---

From: "Morgan, Peter (Engineering)" <[email-masked]>
Date: Mon, 23 Dec 2002 17:27:42 -0000

Maarten,

>These CPs and CIs are explicitly defined in ETSI EN 300 417-4-1, EN 400
417-5-1,
>Rec. G.705, G.783, I.732 and can as such be referred to from the PWE3 RFCs.

Are there any PWE3 RFCs?

Peter.

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: 23 December 2002 13:33
To: [email-masked]
Subject: Re: [PWE3] I-D ACTION:draft-riegel-pwe3-tdm-requirements-01.txt

I would like to propose to extend the requirements document with a more
specific
identification of the ingress/egress points of a PW. I.e. a PW connects
essentially two (ITU-T G.805) Connection Points (CP) within a layer network.

E1 PW connects two P12x_CPs for case of transparent (unstructured) service:

E1 PW connects two P12s_CPs for case of transparent frame-synchronous
service:

T1 PW connects two P11x_CPs for case of transparent (unstructured) service:

VC-n (n=11,12,2,3,4,4-4c,4-16c,4-64c) PW connects two Sn_CPs for case of
transparent service:

The information transported is the Characteristic Information (CI). 
E.g. over the VC-n CP and VC-n PW flows the VC-n CI.
These CPs and CIs are explicitly defined in ETSI EN 300 417-4-1, EN 400
417-5-1,
Rec. G.705, G.783, I.732 and can as such be referred to from the PWE3 RFCs.

P0_CI:   17/G.705

For the case a PW supports multiplexing, the PW is a Link with multiple Link
Connections.
Example VC-n PW with 5x VC-n:

The PW connects via the CPs at its edge to atomic functions defined in
G.705,
G.783, I.732, etc. This can be an adaptation function or a connection
function.
Example: VC-4 PW with STM-1 and STM-4 interfaces and no flexibility in STM-4
interface

                                                      -----------
                                                      --------- |
                                                      ------- | |
                                                            | | |
               S4_CP                             S4_CP      | | |

When there would be flexibility in the selection of the VC-4 in the STM-4
interface, a VC-4 connection function (S4_C) is included and connected to
the
VC-4 PW

                                           -----------------------
                                           |         S4_C        |
                                           -----------------------
               S4_CP                        |             | | | |

The PW can be modelled as well with similar atomic functions... in this
example
there would be a MPLS-VC/S4_A function at each edge of the PW connected via
a
MPLS-VC trail...

                                           -----------------------
                                           |         S4_C        |
                                           -----------------------
               S4_CP                        |             | | | |

              P12x_CP                            P12x_CP

Adding these network architecture models to the PWE3 architecture document,
would connect existing specifications in ITU-T with the PWE3 specifications
not
leaving any ambiguity about the actual signals transported via a PW. 
It also adds implicitly the interface specifications of the interfaces that
provide access to these PWs. Example: G.705 specifies how to access the
P12x_CP
(via e.g. E12_TT and E12/P12x_A functions), while G.783 specifies access to
this
P12x_CP via OSn, RSn, MSn, S4 and finally S12_TT and S12/P12x_A functions.

When the PW is able to multiplex multiple signals, the MPLS-VC/Client_A
function
will have multiple Client_CPs. E.g. for case of PW capable to multiplex 5
VC-12
signals:

             | | | | | 
             O O O O O S12_CPs
             | | | | |
           MPLS-VC/S12_A
                 |
             MPLS-VC_TT
                 |

Regards,

Maarten

---

From: Max Riegel <[email-masked]>
Date: Mon, 23 Dec 2002 23:07:32 +0100

Ron,

>  SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3 

O.k.  Will be corrected in the next revision.

> Plesiosynchronous mode is the rare case.

The drawings and the text are reflecting the most general case. I have 
concerns showing one of the CEs in loop timing for the Adaptive Network 
Scenario as well as the Relative Network Scenario as it may lead to 
assumptions for the behaviour of the PEs which are only sufficient for the 
special (but more common) case of loop timing. I would prefer to keep the 
more generic cases here to avoid too many special modes for clock recovery.

Bye
Max

>>http://www.ietf.org/internet-drafts/draft-riegel-pwe3-tdm-requ
> 
> irements-01.txt
>

---

From: Max Riegel <[email-masked]>
Date: Tue, 24 Dec 2002 00:11:40 +0100

Lloyd Wood wrote:
> On Fri, 20 Dec 2002, Danny McPherson wrote:
> I think the doc's unclear on its scope. well, possibly just its
> terminology.

The scope of the document is not unclear, but perhaps there is not full 
global alignment in the terminology. The ambiguity might be caused by 
different use of the term "TDM".

 > TDM is furthermore used in e.g. SDH/SONET and OTN.

You hit the point: TDM means "Time Devision Multiplexing", a technique 
which is used in E1, T1, E3, T3 as well as in SONET/SDH and others. It 
might be difficult (and dangerous) to use this term just as a reference to 
     bit streams according to the Plesiochronous Digital Hierarchy. But 
I've found that this particular usage is common throughout the I-Ds 
discussed in this group.

Would you have a proposal how to solve this ambiguity?

> 
> what's [PWE3-LAYERS]? cited, not referenced.

Editor's fault:-(. [PWE3-LAYERS] was recently merged into [PWE3-REQ] and 
by changing the references I missed one place in the document.

Bye
Max

---

From: [email-masked]
Date: Tue, 24 Dec 2002 04:03:13 -0000

Maarten....Great to see you taking time to introduce some func arch rigour
in here.  We need this.

regards, Neil