Network Working Group S. Shimizu Request for Comments: 3186 T. Kawano Category: Informational K. Murakami NTT Network Innovation Labs. E. Beier DeTeSystem December 2001
MAPOS/PPP Tunneling mode
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2001). All Rights Reserved.
This memo documents a way of tunneling PPP over Sonet over MAPOS networks. This document is NOT the product of an IETF working group nor is it a standards track document. It has not necessarily benefited from the widespread and in depth community review that standards track documents receive.
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.
c) PPP frame header +-----------+-----------+-----------+-----------+ | Address | Control | Protocol | | fixed,0xFF| fixed,0x03| 16 bits | +-----------+-----------+-----------+-----------+
Figure 1. Header similarity of MAPOS frame and POS frame
This means that a MAPOS network can easily carry POS frames with no additional header overhead by rewriting only 1 or 2 octets. PPP tunneling configuration over MAPOS networks (MAPOS/PPP tunneling mode) provides for efficient L2 multiplexing by which users can share the cost of high speed long-haul 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 that converts between POS header and 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.
Implementation issues are discussed in Chapter 3. Security considerations are noted in Chapter 4.
MAPOS/PPP tunneling mode is based on header rewriting. Figure 2. shows an example of MAPOS/PPP tunneling mode. The MAPOS network uses MAPOS 16  in this example. Consider a tunneling path between customer premise equipment (CPE) A and CPE B which are industry standard POS equipment. The ingress/egress MAPOS switches A/B assigns unique MAPOS addresses (0x0203 and 0x0403) to the CPEs. These MAPOS addresses are used in the MAPOS network, for frame forwarding between CPE A and CPE B. NSP  will not be running between the CPEs and the switches in this case.
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 the MAPOS network and arrives at the egress MAPOS switch B which rewrites the first 2 octets to their original values. If MAPOS v1  is used in the MAPOS network, only the first octet is rewritten.
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 those of PPP over SONET/SDH .
Shimizu, et al. Informational [Page 3]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
SONET/SDH overheads are terminated at the ingress/egress switches. SONET/SDH performance monitors and alarms are used for the link management between a CPE and the switch. Inter-switch links are similarly managed by SONET/SDH monitors and alarms.
A CPE should synchronize to the clock of the border MAPOS switch. The corresponding port of the MAPOS switch uses its internal clock. When the CPE is connected to the MAPOS switch through SONET/SDH transmission equipment, both should synchronize to the clock of the SONET/SDH transmission equipment.
Link layer framing between CPE and MAPOS switch also follows the specification of PPP over SONET/SDH .
HDLC operation including byte stuffing, scrambling, FCS generation is terminated at the ingress/egress switch. In a MAPOS switch, HDLC frame  is picked up from a SONET/SDH payload and the first octet (HDLC address) for MAPOS v1 , or the first two octets (HDLC address and control field) for MAPOS 16  are rewritten. The operation inside the border switch is as follows:
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  and for MAPOS networks.
Maximum transmission unit (MTU) of the link must not be negotiated larger than MAPOS-MTU which is 65280 octets.
Figure 3 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 piggy-back encapsulation, but it is a transparent link with no additional header overhead.
<--- Transmission +----------+----------+----------+----------+ | Flag | Address | Control | Protocol | | 01111110 | 11111111 | 00000011 | 16 bits | +----------+----------+----------+----------+ +-------------+---------+----------+----------+----------------- | Information | Padding |HDLC FCS | Flag | Inter-frame Fill | * | * |16/32 bits| 01111110 | or next Address +-------------+---------+----------+----------+-----------------
(a) HDLC frame from/to CPE
<--- Transmission +----------+----------+----------+----------+ | 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 3. HDLC frame from/to CPE and its conversion
2.3 Operation, Administration, Management and Provisioning (OAM&P)
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 (see 2.3.1).
b) 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.
Shimizu, et al. Informational [Page 6]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
Then, those ports should be configured to MAPOS/PPP tunneling mode on both of the switches. Frame reachability is provided by SSP  in the MAPOS network. When the frame forwarding for each direction are 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.
When any link or node failure is detected, it should be indicated to each peer of the path. This is done by PPP  keep-alive (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 due to keep-alive expiration.
For example, Figure 5 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 keep-alive 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'
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 queuing 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 can be applied to the MAPOS/PPP tunneling mode, MAPOS 16 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.
Figure 6 shows an example of MAPOS network with four switches. Inter-switch links are provided at OC192c and OC48c rate, customer links are either OC3c or OC12c rate. Some links are optically protected. Path database 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 few seconds.
Figure 7. Latency measurement of reference platform for MAPOS/PPP tunneling mode
There is a PPP connection between port 1 and 2 of the measurement equipment. Traffic comes from measurement equipment (IXIA 400) and forwarded by a device under test back to the equipment. Timestamping and latency calculation are performed by IXIA 400 automatically. Traffic Load is set to 30% of OC12c for offloading router.
Results are shown in Table 1. Measurements were taken according to the RFC2544 requirements . We measured 25 trials of 150 seconds duration for each frame size. Results are averaged and rounded to the 20 ns resolution of IXIA. 95% confidence interval (C.I.) value are also rounded.
There is no way to control or attack a MAPOS network from CPE side under PPP tunneling mode. It is quite difficult to inject other stream because it is completely transparent from the viewpoint of the CPE. However, operators must carefully avoid misconfiguration such as path duplication. Per-path isolation is extremely important; switches are recommended to implement this feature (like VLAN mechanism).
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 an isolation feature is implemented in all MAPOS switches in the network. Note that there is no source address field in the MAPOS framing, which may make path isolation difficult in a mixed MAPOS/PPP environment.
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise 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 be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.