< draft-malis-pwe3-sonet-00.txt		draft-malis-pwe3-sonet-01.txt >
	PWE3 Working Group Andrew G. Malis		PWE3 Working Group Andrew G. Malis
	Internet Draft Ken Hsu		Internet Draft Ken Hsu
	Expiration Date: March 2002 Vivace Networks, Inc.		Expiration Date: May 2002 Vivace Networks, Inc.
	Tom Johnson Jeremy Brayley		Tom Johnson Jeremy Brayley
	Marlene Drost Steve Vogelsang		Marlene Drost Steve Vogelsang
	Ed Hallman John Shirron		Ed Hallman John Shirron
	Litchfield Communications, Inc. Laurel Networks, Inc.		Litchfield Communications, Inc. Laurel Networks, Inc.
	Jim Boyle Luca Martini		Jim Boyle Luca Martini
	Protocol Driven Networks, Inc. Craig White		Protocol Driven Networks, Inc. Craig White
	Level 3 Communications, LLC.		Level 3 Communications, LLC.
	Ron Cohen		Ron Cohen
	Lycium Networks David Zelig		Lycium Networks David Zelig
	Corrigent Systems, LTD.		Corrigent Systems, LTD.
	Prayson Pate		Prayson Pate
	Overture Networks, Inc.		Overture Networks, Inc.
	September 2001		November 2001
	SONET/SDH Circuit Emulation over Packet (CEP)		SONET/SDH Circuit Emulation over Packet (CEP)
	draft-malis-pwe3-sonet-00.txt		draft-malis-pwe3-sonet-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of section 10 of RFC 2026 [1].		all provisions of section 10 of RFC 2026 [1].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	5 CEP Operation...............................................9		5 CEP Operation...............................................9
	6 SONET/SDH Maintenance Signals..............................12		6 SONET/SDH Maintenance Signals..............................12
	7 SONET/SDH Transport Timing.................................16		7 SONET/SDH Transport Timing.................................16
	8 SONET/SDH Pointer Management...............................17		8 SONET/SDH Pointer Management...............................17
	9 CEP Performance Monitors...................................18		9 CEP Performance Monitors...................................18
	10 Open Issues................................................20		10 Open Issues................................................20
	11 Security Considerations....................................20		11 Security Considerations....................................20
	12 Intellectual Property Disclaimer...........................20		12 Intellectual Property Disclaimer...........................20
	13 References.................................................22		13 References.................................................22
	14 Acknowledgments............................................23		14 Acknowledgments............................................23
	15 AuthorÆs Addresses.........................................23		15 Author's Addresses.........................................23
	1 Conventions used in this document		1 Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [2].		document are to be interpreted as described in RFC 2119 [2].
	2 Introduction		2 Introduction
	This document describes a protocol that performs SONET Emulation		This document describes a protocol that performs SONET Emulation
	over a variety of Packet-Switched Networks (PSNs) as part of the		over a variety of Packet-Switched Networks (PSNs) as part of the
	PWE3 Working Group. The document assumes that the reader is		PWE3 Working Group. The document assumes that the reader is
	familiar with the PWE3 terminology and concepts described in PWE3		familiar with the PWE3 terminology and concepts described in PWE3
	requirements and framework documents [3] and [4]. The protocol is		requirements and framework documents [3] and [4]. The protocol is
	titled ôCircuit Emulation over Packetö (CEP).		titled "Circuit Emulation over Packet" (CEP).
	The transmission system for circuit-oriented TDM signals is the		The transmission system for circuit-oriented TDM signals is the
	Synchronous Optical Network (SONET) [5], [9] / Synchronous Digital		Synchronous Optical Network (SONET) [5], [9] / Synchronous Digital
	Hierarchy (SDH) [6]. To support TDM traffic (which includes voice,		Hierarchy (SDH) [6]. To support TDM traffic (which includes voice,
	data, and private leased line services) PSNs must emulate the		data, and private leased line services) PSNs must emulate the
	circuit characteristics of SONET/SDH payloads. A circuit identifer		circuit characteristics of SONET/SDH payloads. A circuit identifer
	and a CEP header are used to encapsulate the SONET/SDH TDM signals		and a CEP header are used to encapsulate the SONET/SDH TDM signals
	for transmission over an arbitrary PSN.		for transmission over an arbitrary PSN.
	This document also describes an optional extension to CEP called		This document also describes an optional extension to CEP called
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	packet network. See Table 1 and section 5 for further details.		packet network. See Table 1 and section 5 for further details.
	The N and P bits: MAY be used to explicitly relay negative and		The N and P bits: MAY be used to explicitly relay negative and
	positive pointer adjustment events across the PSN. They are also		positive pointer adjustment events across the PSN. They are also
	used to relay SONET/SDH maintenance signals such as AIS-P. See		used to relay SONET/SDH maintenance signals such as AIS-P. See
	Table 1 and sections 6 and 8 for more details.		Table 1 and sections 6 and 8 for more details.
	+---+---+---+----------------------------------------------+		+---+---+---+----------------------------------------------+
	| D | N | P | Interpretation |		| D | N | P | Interpretation |
	+---+---+---+----------------------------------------------+		+---+---+---+----------------------------------------------+
	| 0 | 0 | 0 | Normal Mode û No Ptr Adjustment |		| 0 | 0 | 0 | Normal Mode - No Ptr Adjustment |
	| 0 | 0 | 1 | Normal Mode û Positive Ptr Adjustment |		| 0 | 0 | 1 | Normal Mode - Positive Ptr Adjustment |
	| 0 | 1 | 0 | Normal Mode û Negative Ptr Adjustment |		| 0 | 1 | 0 | Normal Mode - Negative Ptr Adjustment |
	| 0 | 1 | 1 | Normal Mode û AIS-P |		| 0 | 1 | 1 | Normal Mode - AIS-P |
	| | | | |		| | | | |
	| 1 | 0 | 0 | DBA Mode û STS SPE Unequipped |		| 1 | 0 | 0 | DBA Mode - STS SPE Unequipped |
	| 1 | 0 | 1 | DBA Mode û STS SPE Unequipped Pos Ptr Adj |		| 1 | 0 | 1 | DBA Mode - STS SPE Unequipped Pos Ptr Adj |
	| 1 | 1 | 0 | DBA Mode û STS SPE Unequipped Neg Ptr Adj |		| 1 | 1 | 0 | DBA Mode - STS SPE Unequipped Neg Ptr Adj |
	| 1 | 1 | 1 | DBA Mode û AIS-P |		| 1 | 1 | 1 | DBA Mode - AIS-P |
	+---+---+---+----------------------------------------------+		+---+---+---+----------------------------------------------+
	Table 1. Interpretation of D, N, and P bits		Table 1. Interpretation of D, N, and P bits
	Sequence Number[0:13]: This is a packet sequence number, which MUST		Sequence Number[0:13]: This is a packet sequence number, which MUST
	continuously cycle from 0 to 0x3FFF. It SHOULD begin at zero when a		continuously cycle from 0 to 0x3FFF. It SHOULD begin at zero when a
	CEP channel is created.		CEP channel is created.
	Structure Pointer[0:12]: The Structure Pointer MUST contain the		Structure Pointer[0:12]: The Structure Pointer MUST contain the
	offset of the J1 byte within the CEP SPE Fragment. The value is		offset of the J1 byte within the CEP SPE Fragment. The value is
	skipping to change at page 11, line 49 ¶		skipping to change at page 11, line 49 ¶
	A key component in declaring the state of a CEP service is whether		A key component in declaring the state of a CEP service is whether
	or not the CEP de-packetizer is in or out of packet synchronization.		or not the CEP de-packetizer is in or out of packet synchronization.
	The following paragraphs describe how that determination is made.		The following paragraphs describe how that determination is made.
	As discussed in section 5, a CEP de-packetizer MAY or MAY NOT		As discussed in section 5, a CEP de-packetizer MAY or MAY NOT
	support re-ordering of mis-ordered packets.		support re-ordering of mis-ordered packets.
	As packets are received from the PSN, they are placed into a jitter		As packets are received from the PSN, they are placed into a jitter
	buffer prior to play out on the SONET interface. If a CEP de-		buffer prior to play out on the SONET interface. If a CEP de-
	packetizer supports re-ordering, any packet received before itÆs		packetizer supports re-ordering, any packet received before it's
	play out time will still be considered valid.		play out time will still be considered valid.
	If a CEP de-packetizer does not support re-ordering, a number of		If a CEP de-packetizer does not support re-ordering, a number of
	approaches may be used to minimize the impact of mis-ordered or lost		approaches may be used to minimize the impact of mis-ordered or lost
	packets on the final re-assembled SONET stream. For example, AAL1		packets on the final re-assembled SONET stream. For example, AAL1
	[11] uses a simple state-machine to re-order packets in a sub-set of		[11] uses a simple state-machine to re-order packets in a sub-set of
	possible cases. The algorithm for these state-machines is outside		possible cases. The algorithm for these state-machines is outside
	of the scope of CEP.		of the scope of CEP.
	However, the final determination as to whether or not to declare		However, the final determination as to whether or not to declare
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 22 ¶
	Therefore, the determination of acquisition or loss of packet		Therefore, the determination of acquisition or loss of packet
	synchronization is always made at SONET play-out time. During SONET		synchronization is always made at SONET play-out time. During SONET
	play-out, the CEP de-packetizer will play received CEP packets onto		play-out, the CEP de-packetizer will play received CEP packets onto
	the SONET interface. However, if the jitter buffer is empty or the		the SONET interface. However, if the jitter buffer is empty or the
	packet to be played out has not been received, the CEP de-packetizer		packet to be played out has not been received, the CEP de-packetizer
	will have to play out an empty packet onto the SONET interface in		will have to play out an empty packet onto the SONET interface in
	place of the unavailable packet.		place of the unavailable packet.
	The acquisition of packet synch is based on the number of sequential		The acquisition of packet synch is based on the number of sequential
	CEP packets that are played onto the SONET interface. While, loss		CEP packets that are played onto the SONET interface. While, loss
	of packet synch is based on the number of sequential æemptyÆ packets		of packet synch is based on the number of sequential 'empty' packets
	that are played onto the SONET interface. Specific details of these		that are played onto the SONET interface. Specific details of these
	two cases is described below.		two cases is described below.
	5.4.1 Acquisition of Packet Synchronization		5.4.1 Acquisition of Packet Synchronization
	At startup, a CEP de-packetizer will be out of packet		At startup, a CEP de-packetizer will be out of packet
	synchronization by default. To declare packet synchronization at		synchronization by default. To declare packet synchronization at
	startup or after a loss of packet synchronization, the CEP de-		startup or after a loss of packet synchronization, the CEP de-
	packetizer must play-out a configurable number of CEP packets with		packetizer must play-out a configurable number of CEP packets with
	sequential sequence numbers towards the SONET interface.		sequential sequence numbers towards the SONET interface.
	skipping to change at page 15, line 18 ¶		skipping to change at page 15, line 18 ¶
	and the D-bit MUST be set to one to indicate that the SPE is not		and the D-bit MUST be set to one to indicate that the SPE is not
	being carried through the packet network. Only the CEP header, the		being carried through the packet network. Only the CEP header, the
	Circuit ID Word, and the PSN Header MUST be transmitted into the		Circuit ID Word, and the PSN Header MUST be transmitted into the
	packet network.		packet network.
	6.1.2 STS SPE Unequipped Indication		6.1.2 STS SPE Unequipped Indication
	The declaration of STS SPE unequipped MUST conform to [9]. Quoted		The declaration of STS SPE unequipped MUST conform to [9]. Quoted
	below:		below:
	ôR6-135 [481] STS PTE shall detect an STS Path Unequipped (UNEQ-P)		"R6-135 [481] STS PTE shall detect an STS Path Unequipped (UNEQ-P)
	defect within 10 ms of the onset of at least five consecutive		defect within 10 ms of the onset of at least five consecutive
	samples (which may or may not be consecutive frames) of unequipped		samples (which may or may not be consecutive frames) of unequipped
	STS Signal Labels (C2 byte), as specified in Table 6-2ö		STS Signal Labels (C2 byte), as specified in Table 6-2"
	The termination of STS SPE unequipped MUST also conform to [9].		The termination of STS SPE unequipped MUST also conform to [9].
	ôR6-137 [485v2] STS PTE shall terminate an UNEQ-P defect within 10		"R6-137 [485v2] STS PTE shall terminate an UNEQ-P defect within 10
	ms of the onset of at least five consecutive samples (which may or		ms of the onset of at least five consecutive samples (which may or
	may not be consecutive frames) of STS Signal Labels that are not		may not be consecutive frames) of STS Signal Labels that are not
	unequipped or all-ons, as specified in Table 6-2ö		unequipped or all-ons, as specified in Table 6-2"
	For normal operation during SPE Unequipped, the N and P bits MUST be		For normal operation during SPE Unequipped, the N and P bits MUST be
	interpreted as usual. The SPE MUST be transmitted into the packet		interpreted as usual. The SPE MUST be transmitted into the packet
	network along with the CEP Header, the Circuit ID Word, and PSN		network along with the CEP Header, the Circuit ID Word, and PSN
	Header, and the D-Bit MUST be set to zero.		Header, and the D-Bit MUST be set to zero.
	If DBA has been enabled for STS SPE Unequipped and the Unequipped is		If DBA has been enabled for STS SPE Unequipped and the Unequipped is
	occurring on the SONET/SDH channel, the D-bit MUST be set to one to		occurring on the SONET/SDH channel, the D-bit MUST be set to one to
	indicate DBA is active. Only the CEP Header, the Circuit ID Word,		indicate DBA is active. Only the CEP Header, the Circuit ID Word,
	and PSN Header MUST be transmitted into the packet network. The N		and PSN Header MUST be transmitted into the packet network. The N
	skipping to change at page 16, line 19 ¶		skipping to change at page 16, line 19 ¶
	bits set to one, and the D-bit set to zero. This is an explicit		bits set to one, and the D-bit set to zero. This is an explicit
	indication of AIS-P being received at the far-end of the packet		indication of AIS-P being received at the far-end of the packet
	network, with DBA disabled for AIS-P. The CEP de-packetizer MUST		network, with DBA disabled for AIS-P. The CEP de-packetizer MUST
	play out the received SPE fragment (which will incidentally be		play out the received SPE fragment (which will incidentally be
	carrying all ones), and MUST configure the SONET/SDH Overhead to		carrying all ones), and MUST configure the SONET/SDH Overhead to
	signal AIS-P as defined in [5], [6], and [9].		signal AIS-P as defined in [5], [6], and [9].
	The second case is the receipt of CEP packets with the N and P bits		The second case is the receipt of CEP packets with the N and P bits
	set to one, and the D-bit set to one. This indicates that AIS-P is		set to one, and the D-bit set to one. This indicates that AIS-P is
	being received at the far-end of the packet network, with DBA		being received at the far-end of the packet network, with DBA
	enabled for AIS-P. The CEP de-packetizer MUST play out one packetÆs		enabled for AIS-P. The CEP de-packetizer MUST play out one packet's
	worth of all ones for each packet received, and MUST configure the		worth of all ones for each packet received, and MUST configure the
	SONET/SDH Overhead to signal AIS-P as defined in [5], [6], and [9].		SONET/SDH Overhead to signal AIS-P as defined in [5], [6], and [9].
	A third case that will cause a CEP de-packetization function to play		A third case that will cause a CEP de-packetization function to play
	out an AIS-P indication onto a SONET/SDH channel is during loss of		out an AIS-P indication onto a SONET/SDH channel is during loss of
	packet synchronization. The CEP de-packetizer MUST configure the		packet synchronization. The CEP de-packetizer MUST configure the
	SONET/SDH Overhead to signal AIS-P as defined in [5], [6], and [9].		SONET/SDH Overhead to signal AIS-P as defined in [5], [6], and [9].
	6.2.2 STS SPE Unequipped Indication		6.2.2 STS SPE Unequipped Indication
	skipping to change at page 18, line 16 ¶		skipping to change at page 18, line 16 ¶
	transmitted in three consecutive packets by the packetizer. The de-		transmitted in three consecutive packets by the packetizer. The de-
	packetizer MUST play out the pointer adjustment event when any one		packetizer MUST play out the pointer adjustment event when any one
	packet with N/P bit set is received.		packet with N/P bit set is received.
	References [5],[6],and [9] specify that pointer adjustment events		References [5],[6],and [9] specify that pointer adjustment events
	MUST be separated by three SONET/SDH frames without a pointer		MUST be separated by three SONET/SDH frames without a pointer
	adjustment event. In order to explicitly relay all legal pointer		adjustment event. In order to explicitly relay all legal pointer
	adjustment events, the packet size for a specific circuit SHOULD be		adjustment events, the packet size for a specific circuit SHOULD be
	no larger than (783 * 4 * N)/3, where N is the STS-Nc multiplier.		no larger than (783 * 4 * N)/3, where N is the STS-Nc multiplier.
	In addition, it is possible for pointer adjustments to occur in back		However, there are many SONET implementations which will allow
	to back SONET/SDH frames. In order to support this possibility,		pointer adjustments to occur in back to back SONET/SDH frames. In
	EPAR implementations SHOULD set the packet size for a particular		order to support this possibility, EPAR implementations SHOULD set
	circuit to be no larger than (783*N)/3. Where N is the STS-Nc		the packet size for a particular circuit to be no larger than
	multiplier.		(783*N)/3. Where N is the STS-Nc multiplier.
	Since the minimum value of N is one, EPAR implementations SHOULD		Since the minimum value of N is one, EPAR implementations SHOULD
	support a minimum payload length of 783/3 or 261 bytes.		support a minimum payload length of 783/3 or 261 bytes.
	For EPAR implementations, the CEP de-packetizer MUST utilize the CEP		For EPAR implementations, the CEP de-packetizer MUST utilize the CEP
	sequence numbers to insure that SONET/SDH pointer adjustment events		sequence numbers to insure that SONET/SDH pointer adjustment events
	are not played any more frequently than once per every three CEP		are not played any more frequently than once per every three CEP
	packets transmitted by the remote CEP packetizer.		packets transmitted by the remote CEP packetizer.
	If both bits are set, then an AIS-P event has occurred (this is		If both bits are set, then an AIS-P event has occurred (this is
	skipping to change at page 22, line 11 ¶		skipping to change at page 22, line 11 ¶
	applications relating to the CEP technology outlined in this		applications relating to the CEP technology outlined in this
	document. Vivace Networks, Inc. will grant free unlimited licenses		document. Vivace Networks, Inc. will grant free unlimited licenses
	for use of this technology.		for use of this technology.
	13 References		13 References
	[1] Bradner, S., "The Internet Standards Process -- Revision 3",		[1] Bradner, S., "The Internet Standards Process -- Revision 3",
	BCP 9, RFC 2026, October 1996.		BCP 9, RFC 2026, October 1996.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997		Levels", BCP 14, RFC 2119, May 1997
	[3] Xiao et al, " Requirements for Pseudo-Wire Emulation Edge-to-		[3] Xiao et al, " Requirements for Pseudo-Wire Emulation Edge-to-
	Edge (PWE3)", draft-ietf-pwe3-requirements-01.txt, work in		Edge (PWE3)", draft-ietf-pwe3-requirements-01.txt, work in
	progress, July 2001		progress, July 2001
	[4] Pate et al, ôFramework for Pseudo Wire Emulation Edge-to-Edge		[4] Pate et al, "Framework for Pseudo Wire Emulation Edge-to-Edge
	(PWE3)ö, draft-pate-pwe3-framework-01.txt, work in progress,		(PWE3)", draft-pate-pwe3-framework-01.txt, work in progress,
	July 13, 2001		July 13, 2001
	[5] American National Standards Institute, "Synchronous Optical		[5] American National Standards Institute, "Synchronous Optical
	Network (SONET) - Basic Description including Multiplex		Network (SONET) - Basic Description including Multiplex
	Structure, Rates and Formats," ANSI T1.105-1995.		Structure, Rates and Formats," ANSI T1.105-1995.
	[6] ITU Recommendation G.707, "Network Node Interface For The		[6] ITU Recommendation G.707, "Network Node Interface For The
	Synchronous Digital Hierarchy", 1996.		Synchronous Digital Hierarchy", 1996.
	[7] Malis et al, ôSONET/SDH Circuit Emulation Service Over MPLS		[7] Malis et al, "SONET/SDH Circuit Emulation Service Over MPLS
	(CEM) Encapsulationö, draft-malis-sonet-ces-mpls-05.txt, work		(CEM) Encapsulation", draft-malis-sonet-ces-mpls-05.txt, work
	in progress, July 2001.		in progress, July 2001.
	[8] Danenberg et al, "SONET/SDH Circuit Emulation Service Over PSN		[8] Danenberg et al, "SONET/SDH Circuit Emulation Service Over PSN
	(CEP) Management Information Base Using SMIv2", draft-		(CEP) Management Information Base Using SMIv2", draft-
	danenberg-pw-cem-mib-01.txt, work in progress, July 2001.		danenberg-pw-cem-mib-01.txt, work in progress, July 2001.
	[9] Telcordia Technologies, ôSynchronous Optical Network (SONET)		[9] Telcordia Technologies, "Synchronous Optical Network (SONET)
	Transport Systems: Common Generic Criteriaö, GR-253-CORE, Issue		Transport Systems: Common Generic Criteria", GR-253-CORE, Issue
	3, September 2000.		3, November 2000.
	[10] Worster, ôMPLS Label Stack Encapsulation in IPö, draft-		[10] Worster, "MPLS Label Stack Encapsulation in IP", draft-
	worster-mpls-in-ip-05, work in progress, July 2001.		worster-mpls-in-ip-05, work in progress, July 2001.
	[11] ITU-T, ôRecommendation I.363.1, B-ISDN Adaptation Layer		[11] ITU-T, "Recommendation I.363.1, B-ISDN Adaptation Layer
	Specification: Type AAL1ö, Appendix III, August 1996.		Specification: Type AAL1", Appendix III, August 1996.
	14 Acknowledgments		14 Acknowledgments
	The authors would like to thank all the members of the PWE3 WG who		The authors would like to thank all the members of the PWE3 WG who
	have contributed to this effort.		have contributed to this effort.
	15 AuthorÆs Addresses		15 Author's Addresses
	Andrew G. Malis		Andrew G. Malis
	Vivace Networks, Inc.		Vivace Networks, Inc.
	2730 Orchard Parkway		2730 Orchard Parkway
	San Jose, CA 95134		San Jose, CA 95134
	Email: Andy.Malis@vivacenetworks.com		Email: Andy.Malis@vivacenetworks.com
	Ken Hsu		Ken Hsu
	Vivace Networks, Inc.		Vivace Networks, Inc.
	2730 Orchard Parkway		2730 Orchard Parkway
	skipping to change at page 25, line 23 ¶		skipping to change at page 25, line 23 ¶
	(SPEs). The optical counterpart of the STS-N is the Optical Carrier-		(SPEs). The optical counterpart of the STS-N is the Optical Carrier-
	level N, or OC-N. Table 2 lists standard SONET line rates discussed		level N, or OC-N. Table 2 lists standard SONET line rates discussed
	in this document.		in this document.
	OC Level OC-1 OC-3 OC-12 OC-48 OC-192		OC Level OC-1 OC-3 OC-12 OC-48 OC-192
	SDH Term - STM-1 STM-4 STM-16 STM-64		SDH Term - STM-1 STM-4 STM-16 STM-64
	Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280		Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280
	Table 2. Standard SONET Line Rates		Table 2. Standard SONET Line Rates
	Each SONET frame is 125 ´s and consists of nine rows. An STS-N frame		Each SONET frame is 125 us and consists of nine rows. An STS-N frame
	has nine rows and N*90 columns. Of the N*90 columns, the first N*3		has nine rows and N*90 columns. Of the N*90 columns, the first N*3
	columns are transport overhead and the other N*87 columns are SPEs.		columns are transport overhead and the other N*87 columns are SPEs.
	A number of STS-1s may also be linked together to form a super-rate		A number of STS-1s may also be linked together to form a super-rate
	signal with only one SPE. The optical super-rate signal is denoted		signal with only one SPE. The optical super-rate signal is denoted
	as OC-Nc, which has a higher payload capacity than OC-N.		as OC-Nc, which has a higher payload capacity than OC-N.
	The first 9-byte column of each SPE is the path overhead (POH) and		The first 9-byte column of each SPE is the path overhead (POH) and
	the remaining columns form the payload capacity with fixed stuff		the remaining columns form the payload capacity with fixed stuff
	(STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1		(STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1
	columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed		columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed
	stuff, STS-12c has three columns of fixed stuff, and so on.		stuff, STS-12c has three columns of fixed stuff, and so on.
	The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The		The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The
	payload capacity of an STS-1 is 86 columns (774 bytes) per frame.		payload capacity of an STS-1 is 86 columns (774 bytes) per frame.
	The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame.		The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame.
	Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340		Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340
	bytes per frame. As another example, the payload capacity of an STS-		bytes per frame. As another example, the payload capacity of an STS-
	192c is 149,760 bytes, which is exactly 64 times larger than the		192c is 149,760 bytes, which is 64 times the capacity of an STS-3c.
	STS-3c.
	There are 8,000 SONET frames per second. Therefore, the SPE size,		There are 8,000 SONET frames per second. Therefore, the SPE size,
	(POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112		(POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112
	Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame		Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame
	or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760		or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760
	bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 2		bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 2
	lists the SPE and payload rates supported.		lists the SPE and payload rates supported.
	SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c		SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c
	SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c		SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c
End of changes. 27 change blocks.
	51 lines changed or deleted		50 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/