< draft-shimizu-ppp-mapos-00.txt		draft-shimizu-ppp-mapos-01.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group S. Shimizu		RFC 3186
	INTERNET-DRAFT T. Kawano
	K. Murakami
	NTT Network Innovation Labs.
	E. Beier
	DeTe Systems
	July 2000
	Expires: January 2001
	MAPOS/PPP Tunneling mode
	(draft-shimizu-ppp-mapos-00.txt)
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Distribution of this memo is unlimited. Please send comments to the
	authors <shimizu@ntt-20.ecl.net> <kawano@core.ecl.net>
	<murakami@ntt-20.ecl.net> and <Beier@bina.de>.
	Abstract
	This document specifies tunneling configuration over MAPOS networks.
	Using this mode, a MAPOS network can provide transparent point-to-
	point link for PPP over SONET/SDH (Packet over SONET/SDH, POS)
	without any additional overhead.
	1. Introduction
	MAPOS [1] frame is designed to be similar to PPP over SONET/SDH
	(Packet over SONET/SDH, POS)[2][3] frame. This means that a MAPOS
	network can easily carry POS frames with no additional header
	overhead. PPP tunneling configuration over MAPOS networks (MAPOS/PPP
	tunneling mode) provides an efficiant way of L2 multiplexing by which
	users can share the cost of high speed longhaul links.
	This document specifies MAPOS/PPP tunneling mode. In this mode, a
	MAPOS network provides a point-to-point link for those who intend to
	connect POS equipment. Such link is established within a MAPOS
	switch, or between a pair of MAPOS switches by rewriting POS header
	with MAPOS header for each L2 frame.
	Chapter 2 describes the specification in two parts. First part is
	user network interface (UNI) specification and the second part is
	operation, administration, management and provisioning (OAM&P)
	description. Other issues such as congestion avoidance, end-to-end
	fairness control are out of scope of this document.
	An example of service is given in Chapter 3. Some security issues
	are noted in Chapter 4.
	2. MAPOS/PPP tunneling mode
	2.1 Overview
	MAPOS/PPP tunneling mode is based on header rewriting. Figure 1.
	shows an example of MAPOS/PPP tunneling mode. The MAPOS network uses
	MAPOS 16 [6] in this example. Consider a tunneling path between
	customer premise equipment (CPE) A and CPE B which are industry
	standard POS equipment. Unique MAPOS addresses (0x0203 and 0x0403
	respectively) are assigned to both of CPEs inside MAPOS switches.
	Usually these assignments are predetermined on per port basis.
	From CPE A to CPE B, ingress MAPOS switch A rewrites the first 2
	octets of every frame from CPE A, which are fixed as 0xFF and 0x03,
	to the MAPOS address of its peer, which is 0x0403. Frames are
	forwarded by MAPOS network and arrives at the egress MAPOS switch B
	which rewrites the first 2 octets to their original values. Vice
	versa for packet from CPE B to CPE A. If MAPOS v1 [5] is used in the
	MAPOS network, only the first octet is rewritten.
	+-----+ POS/0x0203 +--------+ +--------+
	|CPE A|<---------->|MAPOS | MAPOS |MAPOS |<---
	+-----+ --->|switch A|------------------|switch |<---
	+--------+\__ Networks __/+--------+
	\__ __/
	+--------+ +-|-----|-+ POS/0x0403 +-----+
	--->|MAPOS |----|MAPOS |<---------->|CPE B|
	--->|switch | |switch B |<--- +-----+
	+--------+ +---------+
	Figure 1. MAPOS/PPP tunneling mode
	The tunneling path between the two CPEs is managed by each
	ingress/egress MAPOS switches.
	2.2 User-Network Interface(UNI)
	2.2.1 Physical Layer
	For transport media between border MAPOS switch and CPE, SONET/SDH
	signal is utilized. Signal speed, path signal label, light power
	budget and all physical requirements are the same as PPP over
	SONET/SDH [2].
	SONET/SDH overheads are terminated at the ingress/egress switches.
	This means, SONET/SDH performance monitors and alarms are used only
	for the link between CPE and the switch. Service provider should
	prepare high-reliable inter-switch link by using optically protected
	WDM equipment and/or SONET/SDH protected ring.
	A CPE should synchronize to the clock of the border MAPOS switch.
	The corresponding port of the MAPOS switch uses its internal clock.
	However, when the CPE is connected to the MAPOS switch through
	SONET/SDH network, both should synchronize to the clock of the
	SONET/SDH transmission equipment.
	2.2.2 Link layer
	Link layer framing between CPE and MAPOS switch also follows the
	specification of PPP over SONET/SDH [2].
	HDLC operation including byte stuffing, scrambling, FCS generation
	is terminated at the ingress/egress switch. In a MAPOS switch, HDLC
	frame [3] is picked up from a SONET/SDH payload and the first octet
	(HDLC address) for MAPOS v1 [1], and the first two octets (HDLC
	address and control field) for MAPOS 16 [6] are rewritten. The
	operation inside the border switch is as follows:
	From CPE (Ingress Switch receiving):
	SONET/SDH framing -> X^43+1 Descrambling -> Byte destuffing
	-> FCS detection (if error, silently discard)
	-> L2 HDLC address/control rewriting
	(0xFF -> MAPOS v1 destination address, or
	0xFF03 -> MAPOS 16 destination address)
	-> MAPOS-FCS generation
	-> Byte stuffing -> X^43+1 Scrambling -> SONET/SDH framing
	To CPE (Egress Switch transmitting):
	SONET/SDH framing -> X^43+1 Descrambling -> Byte destuffing
	-> MAPOS-FCS detection (if error, silently discard)
	-> L2 HDLC address/control rewriting
	(MAPOS v1 address -> 0xFF, or
	MAPOS 16 address -> 0xFF03)
	-> FCS generation
	-> Byte stuffing -> X^43+1 Scrambling -> SONET/SDH framing
	For STS-3c-SPE/VC-4, non-scrambled frame can be used for
	compatibility with RFC 1619. However, the use of 32bit-CRC and
	X^43+1 scrambling is recommended in RFC2615 [2] and for MAPOS
	networks.
	Maximum transmission unit (MTU) of the link must not be negotiated
	larger than MAPOS-MTU which is 65280 octets.
	Figure 2 shows a CPE-side L2 frame and the converted frame in the
	ingress/egress MAPOS switches. Note that the MAPOS/PPP tunneling
	mode is not a piggyback encapsulation, but it is a transparent link
	with no additional header overhead.
	+----------+----------+----------+----------+
	| Flag | Address | Control | Protocol |
	| 01111110 | 11111111 | 00000011 | 16 bits |
	+----------+----------+----------+----------+
	+-------------+---------+----------+----------+-----------------
	| Information | Padding | FCS | Flag | Inter-frame Fill
	| * | * |16/32 bits| 01111110 | or next Address
	+-------------+---------+----------+----------+-----------------
	(a) HDLC frame from/to CPE
	+----------+----------+----------+----------+
	| Flag | MAPOS Destination | Protocol |
	| 01111110 | 0xxxxxx0 | xxxxxxx1 | 16 bits |
	+----------+----------+----------+----------+
	+-------------+---------+----------+----------+-----------------
	| Information | Padding |MAPOS FCS | Flag | Inter-frame Fill
	| * | * |16/32 bits| 01111110 | or next Address
	+-------------+---------+----------+----------+-----------------
	(b) Converted MAPOS 16 frame, forwarded in MAPOS networks
	Figure 2. HDLC frame from/to CPE and its conversion
	2.3 Operation, Administration, Management and Provisioning (OAM&P)
	2.3.1 MAPOS port configuration
	When a port of MAPOS switch is configured to PPP tunneling mode, at
	least the following operations are performed in the switch.
	a) Disable NSP [9] and SSP [7] (for the port, same below)
	b) Disable MAPOS broadcast and multicast forwarding
	c) Enable header rewriting function
	d) Reset the Path Signal Label (C2) to 0x16 if X^43+1 scrambling is
	used. The value 0xCF is used for non-scrambled OC3c signal.
	e) Start host-route advertisement (see 2.3.2)
	When the port is configured back to MAPOS mode, reverse order of the
	operations above are performed. That means;
	a) Stop host-route advertisement (see 2.3.4)
	b) Reset the Path Signal Label (C2) to MAPOS default (0x8d)
	c) Disable header rewriting function
	d) Enable MAPOS broadcast and multicast forwarding
	e) Enable NSP [9] and SSP [7]
	2.3.2 Path Establishment
	A MAPOS/PPP tunneling path is established by following steps.
	a) Choose MAPOS address pair on both ingress/egress switches and
	configure their ports to PPP tunneling mode. Switches enable
	their header rewriting process and start advertising host-
	route for the tunneling port.
	b) Wait for host-route exchange and its convergence.
	c) When the routes for both directions become stable, the
	tunneling path is established. The link between the CPEs may
	be set up at that moment; PPP LCP controls are transparently
	exchanged by the CPEs.
	To add a new path, operators should pick unused MAPOS address-pair.
	They may be determined simply by choosing switches and ports for each
	CPE, because there is one-to-one correspondence between MAPOS
	addresses and switch ports.
	Then, those ports should be configured to MAPOS/PPP tunneling mode
	on both of the switches. This triggers header rewriting and host-
	route advertising. Using triggered update of SSP [7], both switches
	will receive a route to each other. When the routes become stable,
	the path is established and frame forwarding is started. Until then,
	the link between border switches and CPE should be down.
	A MAPOS/PPP tunneling path should be managed by the pair of MAPOS
	addresses. It should be carefully handled to avoid misconfiguration
	such as path duplication. For convenient management, path database
	can be used to keep information about pairs of MAPOS addresses. Note
	that the path database is not used for frame forwarding. It is for
	OAM&P use only.
	2.3.3 Failure detection and indication
	When any link or node failure is detected, it should be indicated to
	each peer of the path. This is done by PPP keepalive (LCP Echo
	request/reply) for end-to-end detection.
	Consideration is required to handle SONET/SDH alarms. When a link
	between CPE and the MAPOS switch fails, it is detected by both the
	MAPOS switch and the CPE seeing SONET/SDH alarms. However, far-side
	link remains up and no SONET/SDH error is found; SONET/SDH alarms
	are not transferred to the far end because each optical path is
	terminated in MAPOS network. In this case, the far end will see
	'link up, line protocol down' status because of keepalive expiration.
	For example, figure 3 shows a tunneling path. When link 1 goes
	down, MAPOS sw A and CPE A detects SONET/SDH alarms but MAPOS sw B
	and CPE A' do not see this failure. When PPP keepalive expires, CPE
	A' detects the failure and stops the packet transmission. The same
	mechanism is used for failure within the MAPOS cloud (link 2). When
	a MAPOS switch is down, SSP handles it as a topology change.
	1 2 3
	CPE A <-x-> MAPOS sw A ---(MAPOS cloud)--- MAPOS sw B <---> CPE A'
	Figure 3. Link failure
	2.3.4 Path removal
	A MAPOS/PPP tunneling path is removed by following steps.
	a) Choose the path to remove, configure MAPOS switches on both
	ends of the path to disable the ports connected to the CPEs.
	b) Switches removes host-route entry of peer addresses and
	stops advertising host-route information.
	c) Wait for the host-route information to be cleard from the
	MAPOS network. Path database may be updated that the path is
	removed.
	Frames arriving after the destination port was disabled should be
	silently discarded and should not be forwarded to the port.
	2.3.5 Provisioning and Design Consideration
	Because MAPOS does not have any QoS control at its protocol level,
	and POS does not have flow-control feature, it is difficult to
	guarantee end-end throughput. Sufficient bandwidth for inter-switch
	link should be prepared to support all paths on the link.
	Switches are recommended to ensure per-port fairness using any
	appropriate queueing algorithm. This is especially important for
	over-subscribed configuration, for example to have more than 16 OC12c
	paths on one OC192c inter-switch link.
	Although MAPOS v1 [5] can be applied to the MAPOS/PPP tunneling
	mode, MAPOS 16 [6] is recommended for ease of address management.
	Automatic switch address negotiation mechanism is not suitable for
	the MAPOS/PPP tunneling mode, because the path management mechanism
	becomes much more complex.
	3. Service example
	Figure 4 shows an example of MAPOS network with four switches.
	Inter-switch links are provided at OC192c or OC48c rate, customer
	links are either OC3c or OC12c rate. Some links are optically
	protected. Path Database (Path DB) is used for path management.
	Using MAPOS-netmask with 8 bits, this topology can be extended up to
	64 MAPOS switches, each equipped with up to 127 CPE ports. Switch
	addresses are fixed to pre-assigned values.
	The cost of optical protection (< 50ms) can be shared among paths.
	Unprotected link can also be coupled for more redundancy in case of
	link failure. SSP provides restoration path within a few seconds.
	0x2003+---------+ +---------+ 0x2203
	A----->| MAPOS | OC192c(protected) | MAPOS |<-------A'
	0x2005| Switch 1|=======================| Switch 2| 0x2205
	B----->| 0x2000/8| _________| 0x2200/8|<-------C'
	+---------+ / +---------+
	OC192c| /
	| / OC48c(backup)
	+---------+ / +---------+ 0x2603
	| MAPOS |_________/ | MAPOS |<-------B'
	0x2405| Switch 3|=======================| Switch 4|
	C----->| 0x2400/8| OC192c(protected) | 0x2600/8|
	+---------+ +---------+
	Path database entries:
	-----------------------------------------------------------
	User : Speed : PPP mode : Addrs pair : Status
	-----------------------------------------------------------
	A-A' : OC3c : CRC32, scramble : 0x2003-0x2203 : Up and running
	B-B' : OC12c : CRC32, scramble : 0x2005-0x2603 : B Down
	C-C' : OC3c : CRC16, no-scram : 0x2405-0x2205 : C' Down
	...
	-----------------------------------------------------------
	Figure 4. Example Topology and its Path Management
	4. Security Consideration
	There is no way to control or attack a MAPOS network from CPE side
	under PPP tunneling mode. It is impossible to tap other stream
	because it is completely transparent from the viewpoint of PPP layer.
	However, operaters must carefully avoid misconfiguration such as path
	duplication. Per-path isolation is extremely important.
	In addition, potential vulnerability still exists in a mixed
	environment where PPP tunneling mode and MAPOS native mode coexists
	in the same network. Use of such environment is not recommended,
	until some filter (like VLAN mechanism) is implemented in all MAPOS
	switches in the network. Note that there is no source address field
	in the MAPOS framing.
	For example, each switch may have forwarding database on per-port
	basis. Traffic from a MAPOS node is not forwarded to any of the
	tunneling ports that are listed as host-route entries in the
	forwarding table.
	5. Expiration
	This Internet Draft expires within 6 months from the date of
	submission.
	6. References
	[1] Murakami, K., and Maruyama, M., "MAPOS - Multiple Access
	Protocol over SONET/SDH Version 1", RFC2171, June 1997.
	[2] Malis, A., and Simpson, W., "PPP over SONET/SDH", RFC2615, June
	1999.
	[3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
	1662, Daydreamer, July 1994.
	[4] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
	STD 51, RFC1661, Daydreamer, July 1994.
	[5] Murakami, K., and Maruyama, M., "MAPOS - Multiple Access
	Protocol over SONET/SDH Version 1", RFC2171, June 1997.
	[6] Murakami, K., and Maruyama, M., "MAPOS 16 - Multiple Access
	Protocol over SONET/SDH with 16 Bit Addressing", RFC2175, June
	1997.
	[7] Murakami, K., and Maruyama, M., "A MAPOS version 1 Extension -
	Switch-Switch Protocol", RFC2174, June 1997.
	[8] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -		Title: MAPOS/PPP Tunneling mode
	Node Switch Protocol," RFC-2173, June, 1997.		Author(s): S. Shimizu, T. Kawano, K. Murakami, E. Beier
			Status: Informational
			Date: December 2001
			Mailbox: shimizu@ntt-20.ecl.net, kawano@core.ecl.net,
			murakami@ntt-20.ecl.net, Beier@bina.de
			Pages: 14
			Characters: 27109
			Updates/Obsoletes/SeeAlso: None
	7. Acknowledgements		I-D Tag: draft-shimizu-ppp-mapos-01.txt
	The authors would like to acknowledge the contributions and		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3186.txt
	thoughtful suggestions of Takahiro Sajima.
	8. Author's Address		This document specifies tunneling configuration over MAPOS (Multiple
			Access Protocol over SONET/SDH) networks. Using this mode, a MAPOS
			network can provide transparent point-to-point link for PPP over
			SONET/SDH (Packet over SONET/SDH, POS) without any additional
			overhead.
	Susumu Shimizu		This memo provides information for the Internet community. It does
	Tetsuo Kawano		not specify an Internet standard of any kind. Distribution of this
	Ken Murakami		memo is unlimited.
	NTT Network Innovation Laboratories,
	3-9-11, Midori-cho Musashino-shi
	Tokyo 180-8585 Japan
	Phone: +81 422 59 3323 Fax: +81 422 59 3765
	E-mail: shimizu@ntt-20.ecl.net
	E-mail: kawano@core.ecl.net
	E-mail: murakami@ntt-20.ecl.net
	Eddy Beier
	DeTe Systems
	Nuremberg, Germany
	E-mail: Beier@bina.de
	9. Full Copyright Statement		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	"Copyright (C) The Internet Society (2000). All Rights Reserved.		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and translations of it may be copied and furnished		To: rfc-info@RFC-EDITOR.ORG
	to others, and derivative works that comment on or otherwise		Subject: getting rfcs
	explain it or assist in its implementation may be prepared, copied,
	published and distributed, in whole or in part, without
	restriction of any kind, provided that the above copyright notice
	and this paragraph are included on all such copies and derivative
	works. However, this document itself may not be modified in any
	way, such as by removing the copyright notice or references to the
	Internet Society or other Internet organizations, except as needed
	for the purpose of developing Internet standards in which case the
	procedures for copyrights defined in the Internet Standards
	process must be followed, or as required to translate it into
	languages other than English.
	The limited permissions granted above are perpetual and will not		help: ways_to_get_rfcs
	be revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on		Requests for special distribution should be addressed to either the
	an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		specifically noted otherwise on the RFC itself, all RFCs are for
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		unlimited distribution.echo
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		Submissions for Requests for Comments should be sent to
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 12 change blocks.
	437 lines changed or deleted		32 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/