RFC 3186
MAPOS/PPP Tunneling mode
Part 1 of 3 🎀 more coming, so stay tuned ✨
Okay bestie, let's talk about RFC 3186, called MAPOS/PPP Tunneling mode 🦋 It's an Informational doc, so it's giving "here's some info" and not a standards-track spec. S. Shimizu, T. Kawano, and K. Murakami from NTT Network Innovation Labs. wrote it, with E. Beier from DeTeSystem joining in, and it's dated December 2001 📅 It came out of the Network Working Group. The title block doesn't list anything it obsoletes or updates, so it's a clean slate 💅
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 Notice 💜
Copyright (C) The Internet Society (2001). All Rights Reserved.
IESG Note 🙈
Okay, so this memo documents a way of tunneling PPP over Sonet over MAPOS networks. It is not the product of an IETF working group, and it's not a standards track document either. It hasn't necessarily gotten the big, deep community review that standards track docs get, so keep that in mind 🫶
Abstract ✨
This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks. In this mode, a MAPOS network can give you a transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead 🧚
1. Introduction 🦋
Okay, so the MAPOS [1][2] frame is designed to look a lot like a PPP over SONET/SDH (Packet over SONET/SDH, POS)[3][4] frame. Here's the lineup (Figure 1) 💖
a) MAPOS frame header (version 1)
+-----------+-----------+-----------+-----------+
| Address | Control | Protocol |
| 8 bits | fixed,0x03| 16 bits |
+-----------+-----------+-----------+-----------+
b) MAPOS frame header (MAPOS 16)
+-----------+-----------+-----------+-----------+
| Address | Protocol |
| 16bits | 16 bits |
+-----------+-----------+-----------+-----------+
c) PPP frame header
+-----------+-----------+-----------+-----------+
| Address | Control | Protocol |
| fixed,0xFF| fixed,0x03| 16 bits |
+-----------+-----------+-----------+-----------+
Figure 1. Header similarity of MAPOS frame and POS frameIt's giving compatibility 😭 This means a MAPOS network can carry POS frames with no extra header overhead, because it only has to rewrite 1 or 2 octets. PPP tunneling over MAPOS networks (the MAPOS/PPP tunneling mode) gives you efficient L2 multiplexing, so users can share the cost of high speed long-haul links 💅
This document specifies the MAPOS/PPP tunneling mode. In this mode, a MAPOS network provides a point-to-point link for anyone who wants to connect POS equipment 🌈 That link is set up inside a MAPOS switch, or between a pair of MAPOS switches that converts between the POS header and the MAPOS header for each L2 frame.
Chapter 2 describes the specification in two parts. The first part is the user network interface (UNI) specification, and the second part is the operation, administration, management and provisioning (OAM&P) description. Other issues, like congestion avoidance and end-to-end fairness control, are out of scope of this document 🙈
Implementation issues are discussed in Chapter 3, and security considerations are noted in Chapter 4 🔥
2. MAPOS/PPP tunneling mode 👑
2.1 Overview 🍓
MAPOS/PPP tunneling mode is based on header rewriting. Figure 2. shows an example of it. The MAPOS network uses MAPOS 16 [2] in this example. Picture a tunneling path between customer premise equipment (CPE) A and CPE B, which are both industry standard POS equipment 🧚 The ingress/egress MAPOS switches A/B give the CPEs unique MAPOS addresses (0x0203 and 0x0403). Those addresses are used inside the MAPOS network to forward frames between CPE A and CPE B. In this case, NSP [5] will not be running between the CPEs and the switches.
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. The frames get forwarded by the MAPOS network and arrive at the egress MAPOS switch B, which rewrites the first 2 octets back to their original values. If MAPOS v1 [1] is used in the MAPOS network, only the first octet gets rewritten 💖
+-----+ POS/0x0203 +--------+ +--------+
|CPE A|<---------->|MAPOS | MAPOS |MAPOS |<---
+-----+ --->|switch A|------------------|switch |<---
+--------+\__ Network __/ +--------+
\__ __/
+--------+ +-|-----|-+ POS/0x0403 +-----+
--->|MAPOS |----|MAPOS |<---------->|CPE B|
--->|switch | |switch B |<--- +-----+
+--------+ +---------+
Figure 2. MAPOS/PPP tunneling modeThe tunneling path between the two CPEs is managed by the ingress/egress MAPOS switches 🫶
2.2 User-Network Interface(UNI) 🦋
2.2.1 Physical Layer 🌸
For the transport media between the border MAPOS switch and the CPE, a SONET/SDH signal is used. The signal speed, path signal label, light power budget and all the physical requirements are the same as those of PPP over SONET/SDH [3] ⚡
SONET/SDH overheads are terminated at the ingress/egress switches. SONET/SDH performance monitors and alarms are used for link management between a CPE and the switch. Inter-switch links are managed in a similar way, using SONET/SDH monitors and alarms 💜
A CPE should synchronize to the clock of the border MAPOS switch. The matching port on 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 that SONET/SDH transmission equipment ⏰
2.2.2 Link layer 💅
Link layer framing between the CPE and the MAPOS switch also follows the specification of PPP over SONET/SDH [3] 🎀
HDLC operation, including byte stuffing, scrambling and FCS generation, is terminated at the ingress/egress switch. Inside a MAPOS switch, an HDLC frame [4] is picked up from a SONET/SDH payload, and then the first octet (HDLC address) is rewritten for MAPOS v1 [1], or the first two octets (HDLC address and control field) are rewritten for MAPOS 16 [2]. Here's how the border switch handles it 🔥
From CPE (Ingress Switch receiving):
SONET/SDH framing
-> X^43+1 De-scrambling -> HDLC Byte de-stuffing
-> HDLC 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
-> HDLC Byte stuffing -> X^43+1 Scrambling -> SONET/SDH framingTo CPE (Egress Switch transmitting):
SONET/SDH framing
-> X^43+1 De-scrambling -> HDLC Byte de-stuffing
-> MAPOS-FCS detection (if error, silently discard)
-> L2 HDLC address/control rewriting
(MAPOS v1 address -> 0xFF, or
MAPOS 16 address -> 0xFF03)
-> HDLC FCS generation
-> HDLC Byte stuffing -> X^43+1 Scrambling -> SONET/SDH framingFor STS-3c-SPE/VC-4, a 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 [3] and for MAPOS networks 🌈
The maximum transmission unit (MTU) of the link must not be negotiated larger than the MAPOS-MTU, which is 65280 octets. Yikes, that's a hard limit 😭
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. It's a transparent link with no additional header overhead, which is the whole point 🧚
<--- 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 conversion2.3 Operation, Administration, Management and Provisioning (OAM&P) 🌸
2.3.1 MAPOS/PPP mode transition ✨
When a port of a MAPOS switch is configured to PPP tunneling mode, at least the following operations are performed in the switch 🍓
- a) Disable NSP [5] and SSP [6] (for the port, same below)
- b) Disable MAPOS broadcast and multicast forwarding
- c) Reset the Path Signal Label (C2) to
0x16if X^43+1 scrambling is used. The value0xCFis used for a non-scrambled OC3c signal. - d) Enable header rewriting function to specified destination address
When the port is configured back to MAPOS mode, the reverse order of the operations above is performed. That means:
- a) Disable header rewriting function (for the port, same below)
- b) Reset the Path Signal Label (C2) to MAPOS default (
0x8d) - c) Enable MAPOS broadcast and multicast forwarding
- d) Enable NSP and SSP
SONET/SDH alarms (B1/B2/B3 error exceeding, SLOF, SLOS, etc.) should not affect this transition 💀 Figure 4 shows the mode transition described above 🦋
[MAPOS mode] <----------------------------+
| |
(Disable NSP) (Enable NSP)
(Disable SSP) (Enable SSP)
(Disable Broadcast/ (Enable Broadcast/
Multicast forwarding) Multicast forwarding)
(C2-byte setting to 0x16 or 0xcf) (C2-byte setting to 0x8d)
(Enable Header Rewriting function) (Disable Header Rewriting
| | function)
v |
[PPP mode] --------------------------------+
Figure 4. MAPOS/PPP tunneling mode state transition diagram2.3.2. Path Establishment ✨
okay so a MAPOS/PPP tunneling path gets set up in two steps 💅
- a) Choose a 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, and PPP LCP controls are transparently exchanged by the CPEs 🫶
to add a new path, operators SHOULD pick an unused MAPOS address-pair 🎀 the good news is they MAY be figured out pretty easily, since you just choose the switches and ports for each CPE. that works because there is a one-to-one correspondence between MAPOS addresses and switch ports 🦋
then those ports SHOULD be configured to MAPOS/PPP tunneling mode on both switches. frame reachability is handled by SSP [6] inside the MAPOS network. once the frame forwarding is stable in each direction, the path is established and frame forwarding starts ✨ until that happens, the link between the border switches and the CPE SHOULD be down, no exceptions 🙅♀️
a MAPOS/PPP tunneling path SHOULD be managed by its pair of MAPOS addresses. it SHOULD be handled super carefully so nobody accidentally creates a path duplicate 😭 for easier management, you can use a path database to keep track of the MAPOS address pairs. just know 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 with PPP [7] keep-alive (LCP Echo request/reply) for end-to-end detection 💜
consideration is REQUIRED for SONET/SDH alarms, and this part is kinda tricky 🙈 when a link between the CPE and the MAPOS switch fails, both the MAPOS switch and the CPE see SONET/SDH alarms. BUT the far-side link stays up and no SONET/SDH error shows up there. the alarms are NOT passed along to the far end, because each optical path ends inside the MAPOS network. so the far end just sees 'link up, line protocol down' once its keep-alive expires 💀
check out Figure 5 for an example tunneling path. when link 1 goes down, MAPOS sw A and CPE A see SONET/SDH alarms, but MAPOS sw B and CPE A' don't notice the failure. once the PPP keep-alive expires, CPE A' detects the failure and stops packet transmission 🛑 the same mechanism handles failures inside the MAPOS cloud (link 2). and when a MAPOS switch goes down, SSP treats it as a topology change 🦋
1 2 3
CPE A <-x-> MAPOS sw A ---(MAPOS cloud)--- MAPOS sw B <---> CPE A'
Figure 5. Link failure2.3.4. Path removal
removing a MAPOS/PPP tunneling path takes these steps 🧹
- a) Choose the path to remove, then configure the MAPOS switches on both ends of the path to disable the ports connected to the CPEs.
- b) The path database MAY be updated to show that the path is removed.
- c) When the CPE is detached, the port MAY be reset to MAPOS default configurations.
frames that arrive after the destination port has been disabled SHOULD be silently discarded 🫥 and they SHOULD NOT be forwarded to that port. no ghost frames allowed, periodt 👻
2.3.5. Provisioning and Design Consideration
okay, real talk: MAPOS has no QoS control at its protocol level, and POS has no flow-control feature 😩 so guaranteeing end-to-end throughput is hard. sufficient bandwidth for the inter-switch link SHOULD be prepared to support all the paths on that link 💪
switches are RECOMMENDED to ensure per-port fairness with any appropriate queuing algorithm ⚖️ this matters a LOT for over-subscribed setups, like having more than 16 OC12c paths on one OC192c inter-switch link. the vibes get messy fast without it 🌪️
MAPOS v1 can be used with the MAPOS/PPP tunneling mode, but MAPOS 16 is RECOMMENDED for easier address management 🎀
automatic switch address negotiation is NOT suitable for the MAPOS/PPP tunneling mode, bestie. the path management gets way more complicated, and nobody wants that drama 😤
3. Implementation
3.1. Service example
Figure 6 shows an example MAPOS network with four switches 🗺️ the inter-switch links run at OC192c and OC48c rates, and the customer links are either OC3c or OC12c. some links are optically protected, and the path database handles path management 🧚
using a MAPOS-netmask with 8 bits, this topology can stretch up to 64 MAPOS switches, each with up to 127 CPE ports 🤯 the switch addresses are fixed to pre-assigned values 📌
the cost of optical protection (< 50ms) can be shared among paths 💸 unprotected links can also be coupled for extra redundancy in case a link fails. SSP gives you a 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 : Mode : Address 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 6. Example Topology and its Path Management3.2. Evaluation of latency of reference implementation
Figure 7 shows the evaluation platforms used to measure latency in MAPOS/PPP tunneling mode 📊
Case 1: Base latency measurement
Measurement
Equipment
+---------+ POS Unidirectional Flow, OC12c 30%, FCS 32bits,
| IXIA 400| payload-scrambling on (same for all cases)
| POS-LM |<--+
| OC12c x2|---+ Loopback
+---------+
(Using IxSoftware v3.1.148/SP1d)
Case 2: Router latency measurement
Measurement Device Under Test
+---------+ POS +------------+
| IXIA 400| Unidirectional Flow | Cisco GSR |
| POS-LM |<---------------------| 12008/1port|
| OC12c x2|--------------------->| OC12cLC x2 |
+---------+ +------------+
(Using IOS 12.0(15)S1)
Case 3: MAPOS/PPP tunneling switch latency measurement
Measurement Device Under Test
+---------+ POS +-------------+
| IXIA 400| Unidirectional Flow | CSR MAPOS |
| POS-LM |<---------------------| CORESwitch80|
| OC12c x2|--------------------->| OC12c x2 |
+---------+ +-------------+
Figure 7. Latency measurement of reference platform for MAPOS/PPP
tunneling modethere is a PPP connection between ports 1 and 2 of the measurement equipment 🔌 traffic comes out of the IXIA 400, gets forwarded by the device under test, and then goes back to the equipment. timestamping and latency calculation are handled automatically by the IXIA 400 🤖 the traffic load is set to 30% of OC12c so the router doesn't get overloaded 🍓
the results are in Table 1. the measurements followed the RFC2544 requirements [8] 📏 we ran 25 trials of 150 seconds for each frame size, averaged the results, and rounded them to the 20 ns resolution of the IXIA. the 95% confidence interval (C.I.) values are rounded too 💅
--------------------------------------------------------------------
Frame size (bytes) 64 128 256 512 1024 1280 1518
--------------------------------------------------------------------
Latency(ns)
--------------------------------------------------------------------
Case 1: Baseline 4060 5640 6940 9840 16420 20700 23340
95% C.I.(+/-) 20 80 60 180 80 100 120
--------------------------------------------------------------------
Case 2: Router 26560 28760 33860 44600 68280 80500 91160
95% C.I.(+/-) 200 100 160 220 100 100 200
--------------------------------------------------------------------
Case 3: Switch 11100 13480 16620 22920 36380 43900 49920
95% C.I.(+/-) 120 120 120 200 100 160 120
--------------------------------------------------------------------
Table 1. Results of Latency (ns) - Frame size (bytes)so these results show that MAPOS/PPP tunneling mode does NOT cause any performance degradation in terms of latency 🙌 a POS L2 switch was reasonably faster than an L3 router 👑
4. Security Considerations ✨
ok this section is serious, bestie 😤🔐 there is no way to control or attack a MAPOS network from the CPE side under PPP tunneling mode. it's really hard to inject other streams because the whole thing is completely transparent from the CPE's point of view. HOWEVER, operators MUST carefully avoid misconfiguration such as path duplication 🚫 per-path isolation is extremely important, so switches are RECOMMENDED to implement it (like the VLAN mechanism) 🛡️
potential vulnerability still exists in a mixed environment where PPP tunneling mode and MAPOS native mode coexist in the same network. use of such an environment is NOT RECOMMENDED until an isolation feature is implemented in all MAPOS switches in the network 💀
also, there is no source address field in the MAPOS framing, which MAY make path isolation difficult in a mixed MAPOS/PPP environment 🙈 stay safe out there 🫶
5. References
- [1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH Version 1", RFC 2171, June 1997.
- [2] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing", RFC 2175, June 1997.
- [3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
- [4] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
- [5] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension - Node Switch Protocol," RFC 2173, June 1997.
- [6] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension - Switch-Switch Protocol", RFC 2174, June 1997.
- [7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
- [8] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
6. Acknowledgments 🌈
the authors would like to acknowledge the contributions and thoughtful suggestions of Takahiro Sajima 🫶💖
7. Author's Address 💌
Okay bestie, here are the humans who wrote this one. Their contact details are copied exactly as they appear in the original:
Susumu Shimizu
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
EMail: shimizu@ntt-20.ecl.netTetsuo Kawano
NTT Network Innovation Laboratories,
3-9-11, Midori-cho Musashino-shi
Tokyo 180-8585 Japan
Phone: +81 422 59 7145
Fax: +81 422 59 4584
EMail: kawano@core.ecl.netKen Murakami
NTT Network Innovation Laboratories,
3-9-11, Midori-cho Musashino-shi
Tokyo 180-8585 Japan
Phone: +81 422 59 4650
Fax: +81 422 59 3765
EMail: murakami@ntt-20.ecl.netEduard Beier
DeTeSystem GmbH
Merianstrasse 32
D-90409 Nuremberg, Germany
EMail: Beier@bina.de8. Full Copyright Statement 🎀
Copyright (C) The Internet Society (2001). All Rights Reserved. 🌸
Here's the legal part, so read it carefully. ✨ You're allowed to copy this document and share it with others, and you can make derivative works that comment on or explain it, or help people implement it. You can publish and distribute those in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph stay on every copy and every derivative work. 💜
The document itself can't be changed in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The one exception is when you need it for developing Internet standards, and then the copyright procedures in the Internet Standards process have to be followed. Translating it into languages other than English is also allowed. 🦋
The limited permissions above are perpetual, meaning they won't be revoked by the Internet Society or its successors or assigns. 💖
The document and the information in it are 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. 😭
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 👑
📦 where this page comes from
- ietf: rfc3186 2001-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms