< draft-malis-pwe3-sonet-01.txt		draft-malis-pwe3-sonet-02.txt >
	PWE3 Working Group Andrew G. Malis		PWE3 Working Group Andrew G. Malis
	Internet Draft Ken Hsu		Internet Draft Ken Hsu
	Expiration Date: May 2002 Vivace Networks, Inc.		Expiration Date: September 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.
	November 2001		March 2002
	SONET/SDH Circuit Emulation over Packet (CEP)		SONET/SDH Circuit Emulation over Packet (CEP)
	draft-malis-pwe3-sonet-01.txt		draft-malis-pwe3-sonet-02.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 27 ¶		skipping to change at page 2, line 27 ¶
	1 Conventions used in this document...........................2		1 Conventions used in this document...........................2
	2 Introduction................................................2		2 Introduction................................................2
	3 Scope.......................................................3		3 Scope.......................................................3
	4 CEP Encapsulation Format....................................4		4 CEP Encapsulation Format....................................4
	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....................................21
	12 Intellectual Property Disclaimer...........................20		12 Intellectual Property Disclaimer...........................21
	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].
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 36 ¶
	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
	from 0 to 0x1FFE, where 0 means the first byte after the CEP header.		from 0 to 0x1FFE, where 0 means the first byte after the CEP header.
	The Structure Pointer MUST be set to 0x1FFF if a packet does not		The Structure Pointer MUST be set to 0x1FFF if a packet does not
	carry the J1 byte. See [5], [6] and [9] for more information on the		carry the J1 byte. See [5], [6] and [9] for more information on the
	J1 byte and the SONET/SDH payload pointer. Implementations MUST		J1 byte and the SONET/SDH payload pointer. Implementations MUST
	support SPE Fragments of up to 1023 bytes and MAY support SPE		support SPE Fragments of 783 bytes and MAY support SPE fragments of
	fragments of up to 8191 bytes.		from 8 to 8191 bytes.
	Note: CEP packets are fixed in length for all of the packets of a		Note 1: Implementations that choose to support programmable payload
			lengths SHOULD support payloads that are an integer multiple of 8
			bytes.
			Note 2: CEP packets are fixed in length for all of the packets of a
	particular emulated TDM stream. This length is statically		particular emulated TDM stream. This length is statically
	provisioned for each TDM stream. Therefore, the length of each CEP		provisioned for each TDM stream. Therefore, the length of each CEP
	packet does not need to be carried in the CEP header.		packet does not need to be carried in the CEP header.
	4.1 PSN Encapsulation		4.1 PSN Encapsulation
	In principle, CEP packets can be carried over any packet-oriented		In principle, CEP packets can be carried over any packet-oriented
	network. The following sections describe specifically how CEP		network. The following sections describe specifically how CEP
	packets MUST be encapsulated for carriage over MPLS or IP networks.		packets MUST be encapsulated for carriage over MPLS or IP networks.
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 21 ¶
	One way to achieve these goals is to map CEP directly onto IP.		One way to achieve these goals is to map CEP directly onto IP.
	Because the Circuit ID Word is essentially an MPLS Shim, the CEP		Because the Circuit ID Word is essentially an MPLS Shim, the CEP
	packet may be treated as an MPLS packet. A mechanism for carrying		packet may be treated as an MPLS packet. A mechanism for carrying
	MPLS over IP is described in [10].		MPLS over IP is described in [10].
	Using this encapsulation scheme would result in the packet format		Using this encapsulation scheme would result in the packet format
	illustrated in figure 6.		illustrated in figure 6.
	+-----------------------------------+		+-----------------------------------+
	| |		| |
	| IPv6/v4 Header [10] |		| IPv6/v4 Header [10] |
	| |		| |
	+-----------------------------------+		+-----------------------------------+
	| Circuit ID Word |		| Circuit ID Word |
	+-----------------------------------+		+-----------------------------------+
	| CEP Header |		| CEP Header |
	+-----------------------------------+		+-----------------------------------+
	| |		| |
	| |		| |
	| SONET/SDH SPE Fragment |		| SONET/SDH SPE Fragment |
	| |		| |
	skipping to change at page 12, line 41 ¶		skipping to change at page 12, line 41 ¶
	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.
	5.4.2 Loss of Packet Synchronization		5.4.2 Loss of Packet Synchronization
	Once a CEP de-packetizer is in packet sync, it may encounter a set		Once a CEP de-packetizer is in packet sync, it may encounter a set
	of events that will cause it to lose packet synchronization.		of events that will cause it to lose packet synchronization.
	If the CEP de-packetizer encounters more than a configurable number		If the CEP de-packetizer encounters more than a configurable number
	of sequentialempty packets, the CEP de-packetizer MUST declare loss		of sequentialempty packets, the CEP de-packetizer MUST declare loss
	of packet synchronization.		of packet synchronization defect .
			LOPS failure is declared after 2.5 +/- 0.5 seconds of LOPS defect,
			and cleared after 10 seconds free of LOPS defect state. The VC is
			considered down as long as LOPS failure is declared.
	6 SONET/SDH Maintenance Signals		6 SONET/SDH Maintenance Signals
	There are several issues that must be considered in the mapping of		There are several issues that must be considered in the mapping of
	maintenance signals between SONET/SDH and a PSN. A description of		maintenance signals between SONET/SDH and a PSN. A description of
	how these signals and conditions are mapped between the two domains		how these signals and conditions are mapped between the two domains
	is described below.		is described below.
	For clarity, the mappings are split into two groups: SONET/SDH to		For clarity, the mappings are split into two groups: SONET/SDH to
	PSN, and PSN to SONET/SDH.		PSN, and PSN to SONET/SDH.
	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.
	However, there are many SONET implementations which will allow		However, there are SONET implementations that allow pointer
	pointer adjustments to occur in back to back SONET/SDH frames. In		adjustments to occur in back to back SONET/SDH frames. In order to
	order to support this possibility, EPAR implementations SHOULD set		support this possibility, EPAR implementations SHOULD set the packet
	the packet size for a particular circuit to be no larger than		size for a particular circuit to be no larger than (783*N)/3. Where
	(783*N)/3. Where N is the STS-Nc multiplier.		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 19, line 18 ¶		skipping to change at page 19, line 18 ¶
	These performance monitors are maintained by the CEP De-Packetizer		These performance monitors are maintained by the CEP De-Packetizer
	during reassembly of the SONET stream.		during reassembly of the SONET stream.
	The performance monitors are based on two types of defects.		The performance monitors are based on two types of defects.
	Type 1 defect is defined as: missing or dropped packet.		Type 1 defect is defined as: missing or dropped packet.
	Type 2 defect is defined as: buffer under run, buffer over-run,		Type 2 defect is defined as: buffer under run, buffer over-run,
	LOPS.		LOPS.
			The specific performance monitors that are defined for CEP are as
			follows:
			ES-CEP - CEP Errored Seconds
			SES-CEP - CEP Severely Errored Seconds
			UAS-CEP - CEP Unavailable Seconds
	Each second that contain at least one type 1 defect SHALL be		Each second that contain at least one type 1 defect SHALL be
	declared as ES-CEP.		declared as ES-CEP.
	Each second that contain type 2 defect, or missing packets above		Each second that contain type 2 defect, or missing packets above
	pre-defined, configurable threshold of missing/dropped packets SHALL		pre-defined, configurable threshold of missing/dropped packets SHALL
	be declared both SES-CEP and ES-CEP. Default value for missing		be declared both SES-CEP and ES-CEP. Default value for missing
	packet to SES is 3.		packet to SES is 3.
	UAS-CES shall be declared after X consecutives SES-CEP, cleared		UAS-CEP SHALL be declared after X consecutives SES-CEP, cleared
	after X consecutive seconds without SES-CEP. Default value of X is		after X consecutive seconds without SES-CEP. Default value of X is
	10 seconds.		10 seconds.
	Once unavailability is declared, ES and SES counts shall be		Once unavailability is declared, ES and SES counts SHALL be
	inhibited up to the point where the unavailability was started. Once		inhibited up to the point where the unavailability was started. Once
	unavailability is removed, ES that occurred along the X seconds		unavailability is removed, ES that occurred along the X seconds
	clearing period shall be added to the ES counts. An update is		clearing period SHALL be added to the ES counts. An update is
	required even for closed intervals if necessary.		required even for closed intervals if necessary.
	LOPS failure is declared after 2.5 +/- 0.5 seconds of LOPS defect,
	and cleared after 10 seconds free of LOPS defect state. The VC is
	considered down as long as LOPS failure is declared.
	FC-CEP is the number of time type 1 or type 2 defect states were		FC-CEP is the number of time type 1 or type 2 defect states were
	declared. The NE shall have thresholding on ES-CEP, SES-CEP and		declared. The NE SHALL have thresholding on ES-CEP, SES-CEP and
	UAS-CEP (thresholding mean activate a notification if more than pre-		UAS-CEP (thresholding mean activate a notification if more than pre-
	defined # of seconds are declared as ES, etc. in 15 minutes		defined # of seconds are declared as ES, etc. in 15 minutes
	interval).		interval).
	9.2 Far-End Performance Monitors		9.2 Far-End Performance Monitors
	These performance monitors provide insight into the CEM De-		These performance monitors provide insight into the CEM De-
	packetizer at the far-end of the PSN.		packetizer at the far-end of the PSN.
	Far end statistics are based on the RDI-CEP bit. Limited		Far end statistics are based on the RDI-CEP bit. Limited
	functionality is supported compared to [GR-253] for simplicity and		functionality is supported compared to [GR-253] for simplicity and
	because it is assumed that all relevant statistics are available		because it is assumed that all relevant statistics are available
	from the end point of the PW. CEP-FE defect is declared when CEP-RDI		from the end point of the PW. CEP-FE defect is declared when CEP-RDI
	is set in the incoming CEP packets.		is set in the incoming CEP packets.
	skipping to change at page 21, line 4 ¶		skipping to change at page 21, line 6 ¶
	transmission of the entire CEP packet stream under certain		transmission of the entire CEP packet stream under certain
	circumstances. Future versions of this draft may define such a		circumstances. Future versions of this draft may define such a
	mechanism.		mechanism.
	11 Security Considerations		11 Security Considerations
	This document does not address or modify security issues within the		This document does not address or modify security issues within the
	relevant PSNs.		relevant PSNs.
	12 Intellectual Property Disclaimer		12 Intellectual Property Disclaimer
	This document is being submitted for use in IETF standards		This document is being submitted for use in IETF standards
	discussions. Vivace Networks, Inc. has filed one or more patent		discussions. Vivace Networks, Inc. has filed one or more patent
	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, May 1997		Levels", BCP 14, RFC 2119, March 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-02.txt, work in
	progress, July 2001		progress, Nov 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-ietf-pwe3-framework-00.txt, work in progress,
	July 13, 2001		Feb, 2002
	[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-02.txt, work in progress, Feb 2002.
	[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, November 2000.		3, September 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
End of changes. 23 change blocks.
	32 lines changed or deleted		43 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/