As per Relevance of the word tunneling, we have this rfc below:
Network Working Group S.
Request for Comments: 3186 T.
Category: Informational K.
NTT Network Innovation Labs
E.
December 2001
MAPOS/PPP Tunneling
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
IESG
This memo documents a way of tunneling PPP over Sonet over
networks. This document is NOT the product of an IETF working
nor is it a standards track document. It has not
benefited from the widespread and in depth community review
standards track documents receive
This document specifies tunneling configuration over MAPOS (
Access Protocol over SONET/SDH) networks. Using this mode, a
network can provide transparent point-to-point link for PPP
SONET/SDH (Packet over SONET/SDH, POS) without any
overhead
1.
MAPOS [1][2] frame is designed to be similar to PPP over SONET/
(Packet over SONET/SDH, POS)[3][4] frame (Figure 1).
Shimizu, et al. Informational [Page 1]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
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
+-----------+-----------+-----------+-----------+
| Address | Control | Protocol |
| fixed,0xFF| fixed,0x03| 16 bits |
+-----------+-----------+-----------+-----------+
Figure 1. Header similarity of MAPOS frame and POS
This means that a MAPOS network can easily carry POS frames with
additional header overhead by rewriting only 1 or 2 octets.
tunneling configuration over MAPOS networks (MAPOS/PPP
mode) provides for efficient L2 multiplexing by which users can
the cost of high speed long-haul links
This document specifies MAPOS/PPP tunneling mode. In this mode,
MAPOS network provides a point-to-point link for those who intend
connect POS equipment. Such link is established within a
switch, or between a pair of MAPOS switches that converts between
header and MAPOS header for each L2 frame
Chapter 2 describes the specification in two parts. First part
user network interface (UNI) specification and the second part
operation, administration, management and provisioning (OAM&P
description. Other issues such as congestion avoidance, end-to-
fairness control are out of scope of this document
Implementation issues are discussed in Chapter 3.
considerations are noted in Chapter 4.
Shimizu, et al. Informational [Page 2]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
2. MAPOS/PPP tunneling
2.1
MAPOS/PPP tunneling mode is based on header rewriting. Figure 2.
shows an example of MAPOS/PPP tunneling mode. The MAPOS network
MAPOS 16 [2] in this example. Consider a tunneling path
customer premise equipment (CPE) A and CPE B which are
standard POS equipment. The ingress/egress MAPOS switches A/
assigns unique MAPOS addresses (0x0203 and 0x0403) to the CPEs
These MAPOS addresses are used in the MAPOS network, for
forwarding between CPE A and CPE B. NSP [5] will not be
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
arrives at the egress MAPOS switch B which rewrites the first 2
octets to their original values. If MAPOS v1 [1] is used in
MAPOS network, only the first octet is 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
The tunneling path between the two CPEs is managed by
ingress/egress MAPOS switches
2.2 User-Network Interface(UNI
2.2.1 Physical
For transport media between border MAPOS switch and CPE, SONET/
signal is utilized. Signal speed, path signal label, light
budget and all physical requirements are the same as those of
over SONET/SDH [3].
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
management between a CPE and the switch. Inter-switch links
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/
transmission equipment, both should synchronize to the clock of
SONET/SDH transmission equipment
2.2.2 Link
Link layer framing between CPE and MAPOS switch also follows
specification of PPP over SONET/SDH [3].
HDLC operation including byte stuffing, scrambling, FCS generation
terminated at the ingress/egress switch. In a MAPOS switch,
frame [4] is picked up from a SONET/SDH payload and the first
(HDLC address) for MAPOS v1 [1], or the first two octets (
address and control field) for MAPOS 16 [2] are rewritten.
operation inside the border switch is as follows
From CPE (Ingress Switch receiving):
SONET/SDH
-> X^43+1 De-scrambling -> HDLC Byte de-
-> HDLC FCS detection (if error, silently discard
-> L2 HDLC address/control
(0xFF -> MAPOS v1 destination address,
0xFF03 -> MAPOS 16 destination address
-> MAPOS-FCS
-> HDLC Byte stuffing -> X^43+1 Scrambling -> SONET/SDH
To CPE (Egress Switch transmitting):
SONET/SDH
-> X^43+1 De-scrambling -> HDLC Byte de-
-> MAPOS-FCS detection (if error, silently discard
-> L2 HDLC address/control
(MAPOS v1 address -> 0xFF,
MAPOS 16 address -> 0xFF03)
-> HDLC FCS
-> HDLC Byte stuffing -> X^43+1 Scrambling -> SONET/SDH
Shimizu, et al. Informational [Page 4]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
For STS-3c-SPE/VC-4, non-scrambled frame can be used
compatibility with RFC 1619. However, the use of 32bit-CRC
X^43+1 scrambling is recommended in RFC2615 [3] and for
networks
Maximum transmission unit (MTU) of the link must not be
larger than MAPOS-MTU which is 65280 octets
Figure 3 shows a CPE-side L2 frame and the converted frame in
ingress/egress MAPOS switches. Note that the MAPOS/PPP
mode is not a piggy-back encapsulation, but it is a transparent
with no additional header overhead
<---
+----------+----------+----------+----------+
| Flag | Address | Control | Protocol |
| 01111110 | 11111111 | 00000011 | 16 bits |
+----------+----------+----------+----------+
+-------------+---------+----------+----------+-----------------
| Information | Padding |HDLC FCS | Flag | Inter-frame
| * | * |16/32 bits| 01111110 | or next
+-------------+---------+----------+----------+-----------------
(a) HDLC frame from/to
<---
+----------+----------+----------+----------+
| Flag | MAPOS Destination | Protocol |
| 01111110 | 0xxxxxx0 | xxxxxxx1 | 16 bits |
+----------+----------+----------+----------+
+-------------+---------+----------+----------+-----------------
| Information | Padding |MAPOS FCS | Flag | Inter-frame
| * | * |16/32 bits| 01111110 | or next
+-------------+---------+----------+----------+-----------------
(b) Converted MAPOS 16 frame, forwarded in MAPOS
Figure 3. HDLC frame from/to CPE and its
2.3 Operation, Administration, Management and Provisioning (OAM&P
2.3.1 MAPOS/PPP mode
When a port of MAPOS switch is configured to PPP tunneling mode,
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
Shimizu, et al. Informational [Page 5]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
c) Reset the Path Signal Label (C2) to 0x16 if X^43+1
is used. The value 0xCF is used for non-scrambled OC3c signal
d) Enable header rewriting function to specified
When the port is configured back to MAPOS mode, reverse order of
operations above are 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
d) Enable NSP and
SONET/SDH alarms (B1/B2/B3 error exceeding, SLOF, SLOS, etc.)
not affect this transition. Figure 4 shows mode transition
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
| | function
v |
[PPP mode] --------------------------------+
Figure 4. MAPOS/PPP tunneling mode state transition
2.3.2 Path
A MAPOS/PPP tunneling path is established by following steps
a) Choose MAPOS address pair on both ingress/egress switches
configure their ports to PPP tunneling mode (see 2.3.1).
b) When the routes for both directions become stable,
tunneling path is established. The link between the CPEs
be set up at that moment; PPP LCP controls are
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
CPE, because there is one-to-one correspondence between
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
both of the switches. Frame reachability is provided by SSP [6]
the MAPOS network. When the frame forwarding for each direction
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
addresses. It should be carefully handled to avoid
such as path duplication. For convenient management, path
can be used to keep information about pairs of MAPOS addresses.
that the path database is not used for frame forwarding. It is
OAM&P use only
2.3.3 Failure detection and
When any link or node failure is detected, it should be indicated
each peer of the path. This is done by PPP [7] keep-alive (LCP
request/reply) for end-to-end detection
Consideration is required to handle SONET/SDH alarms. When a
between CPE and the MAPOS switch fails, it is detected by both
MAPOS switch and the CPE seeing SONET/SDH alarms. However, far-
link remains up and no SONET/SDH error is found; SONET/SDH
are not transferred to the far end because each optical path
terminated in MAPOS network. In this case, the far end will
'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
A' do not see this failure. When PPP keep-alive expires, CPE A
detects the failure and stops the packet transmission. The
mechanism is used for failure within the MAPOS cloud (link 2).
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 5. Link
2.3.4 Path
A MAPOS/PPP tunneling path is removed by following steps
a) Choose the path to remove, configure MAPOS switches on
ends of the path to disable the ports connected to the CPEs
b) Path database may be updated that the path is removed
Shimizu, et al. Informational [Page 7]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
c) When CPE is detached, port may be reset to MAPOS
configurations
Frames arriving after the destination port was disabled should
silently discarded and should not be forwarded to the port
2.3.5 Provisioning and Design
Because MAPOS does not have any QoS control at its protocol level
and POS does not have flow-control feature, it is difficult
guarantee end-end throughput. Sufficient bandwidth for inter-
link should be prepared to support all paths on the link
Switches are recommended to ensure per-port fairness using
appropriate queuing algorithm. This is especially important
over-subscribed configuration, for example to have more than 16 OC12
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
the MAPOS/PPP tunneling mode, because the path management
becomes much more complex
3.
3.1 Service
Figure 6 shows an example of MAPOS network with four switches
Inter-switch links are provided at OC192c and OC48c rate,
links are either OC3c or OC12c rate. Some links are
protected. Path database is used for path management
Using MAPOS-netmask with 8 bits, this topology can be extended up
64 MAPOS switches, each equipped with up to 127 CPE ports.
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
link failure. SSP provides restoration path within few seconds
Shimizu, et al. Informational [Page 8]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
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 :
-----------------------------------------------------------
A-A' : OC3c : CRC32, scramble : 0x2003-0x2203 : Up and
B-B' : OC12c : CRC32, scramble : 0x2005-0x2603 : B
C-C' : OC3c : CRC16, no-scram : 0x2405-0x2205 : C'
-----------------------------------------------------------
Figure 6. Example Topology and its Path
3.2 Evaluation of latency of reference
Figure 7 shows evaluation platforms in terms of latency
of MAPOS/PPP tunneling mode
Shimizu, et al. Informational [Page 9]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
Case 1: Base latency
+---------+ POS Unidirectional Flow, OC12c 30%, FCS 32bits
| IXIA 400| payload-scrambling on (same for all cases
| POS-LM |<--+
| OC12c x2|---+
+---------+
(Using IxSoftware v3.1.148/SP1d
Case 2: Router latency
Measurement Device Under
+---------+ 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 Device Under
+---------+ POS +-------------+
| IXIA 400| Unidirectional Flow | CSR MAPOS |
| POS-LM |<---------------------| CORESwitch80|
| OC12c x2|--------------------->| OC12c x2 |
+---------+ +-------------+
Figure 7. Latency measurement of reference platform for MAPOS/
tunneling
There is a PPP connection between port 1 and 2 of the
equipment. Traffic comes from measurement equipment (IXIA 400)
forwarded by a device under test back to the equipment.
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
the RFC2544 requirements [8]. We measured 25 trials of 150
duration for each frame size. Results are averaged and rounded
the 20 ns resolution of IXIA. 95% confidence interval (C.I.)
are also rounded
Shimizu, et al. Informational [Page 10]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
--------------------------------------------------------------------
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
This results shows that MAPOS/PPP tunneling mode does not cause
performance degradation in terms of latency view. A POS L2
was reasonably faster than a L3 router
4. Security
There is no way to control or attack a MAPOS network from CPE
under PPP tunneling mode. It is quite difficult to inject
stream because it is completely transparent from the viewpoint of
CPE. However, operators must carefully avoid misconfiguration
as path duplication. Per-path isolation is extremely important
switches are recommended to implement this feature (like
mechanism).
In addition, potential vulnerability still exists in a
environment where PPP tunneling mode and MAPOS native mode
in the same network. Use of such environment is not recommended
until an isolation feature is implemented in all MAPOS switches
the network. Note that there is no source address field in the
framing, which may make path isolation difficult in a mixed MAPOS/
environment
Shimizu, et al. Informational [Page 11]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
5.
[1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access
over SONET/SDH Version 1", RFC 2171, June 1997.
[2] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple
Protocol over SONET/SDH with 16 Bit Addressing", RFC 2175,
1997.
[3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
1999.
[4] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
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,
1661, July 1994.
[8] Bradner, S. and J. McQuaid, "Benchmarking Methodology
Network Interconnect Devices", RFC 2544, March 1999.
6.
The authors would like to acknowledge the contributions
thoughtful suggestions of Takahiro Sajima
Shimizu, et al. Informational [Page 12]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
7. Author's
Susumu
NTT Network Innovation Laboratories
3-9-11, Midori-cho Musashino-
Tokyo 180-8585
Phone: +81 422 59 3323
Fax: +81 422 59 3765
EMail: shimizu@ntt-20.ecl.
Tetsuo
NTT Network Innovation Laboratories
3-9-11, Midori-cho Musashino-
Tokyo 180-8585
Phone: +81 422 59 7145
Fax: +81 422 59 4584
EMail: kawano@core.ecl.
Ken
NTT Network Innovation Laboratories
3-9-11, Midori-cho Musashino-
Tokyo 180-8585
Phone: +81 422 59 4650
Fax: +81 422 59 3765
EMail: murakami@ntt-20.ecl.
Eduard
DeTeSystem
Merianstrasse 32
D-90409 Nuremberg,
EMail: Beier@bina.
Shimizu, et al. Informational [Page 13]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
8. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Shimizu, et al. Informational [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
