📄 rfc3186.txt
字号:
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 Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
IESG Note
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.
Abstract
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.
1. Introduction
MAPOS [1][2] frame is designed to be similar to PPP over SONET/SDH
(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 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.
Shimizu, et al. Informational [Page 2]
RFC 3186 MAPOS/PPP Tunneling mode December 2001
2. MAPOS/PPP tunneling mode
2.1 Overview
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 [2] 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 [5] 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 [1] is used in the
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 mode
The 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 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 [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 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.
2.2.2 Link layer
Link layer framing between CPE and MAPOS switch also follows the
specification of PPP over SONET/SDH [3].
HDLC operation including byte stuffing, scrambling, FCS generation is
terminated at the ingress/egress switch. In a MAPOS switch, HDLC
frame [4] is picked up from a SONET/SDH payload and the first octet
(HDLC address) for MAPOS v1 [1], or the first two octets (HDLC
address and control field) for MAPOS 16 [2] are rewritten. The
operation inside the border switch is as follows:
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 framing
To 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 framing
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 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.
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)
2.3.1 MAPOS/PPP mode transition
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 [5] and SSP [6] (for the port, same below)
b) Disable MAPOS broadcast and multicast forwarding
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 scrambling
is used. The value 0xCF is used for non-scrambled OC3c signal.
d) Enable header rewriting function to specified destination
address
When the port is configured back to MAPOS mode, reverse order of the
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 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 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 diagram
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 (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 [6] 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.
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 [7] 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'
Figure 5. 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) Path database may be updated that the path is removed.
Shimizu, et al. Informational [Page 7]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -