summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3186.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3186.txt')
-rw-r--r--doc/rfc/rfc3186.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc3186.txt b/doc/rfc/rfc3186.txt
new file mode 100644
index 0000000..9f0256a
--- /dev/null
+++ b/doc/rfc/rfc3186.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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]
+
+RFC 3186 MAPOS/PPP Tunneling mode December 2001
+
+
+ c) When CPE is detached, port may be reset to MAPOS default
+ configurations.
+
+ 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 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.
+
+3. Implementation
+
+3.1 Service example
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+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 : 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 Management
+
+3.2 Evaluation of latency of reference implementation
+
+ Figure 7 shows evaluation platforms in terms of latency measurement
+ of MAPOS/PPP tunneling mode.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shimizu, et al. Informational [Page 9]
+
+RFC 3186 MAPOS/PPP Tunneling mode December 2001
+
+
+ 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 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 [8]. 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.
+
+
+
+
+
+
+
+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 any
+ performance degradation in terms of latency view. A POS L2 switch
+ was reasonably faster than a L3 router.
+
+4. Security Considerations
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shimizu, et al. Informational [Page 11]
+
+RFC 3186 MAPOS/PPP Tunneling mode December 2001
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shimizu, et al. Informational [Page 12]
+
+RFC 3186 MAPOS/PPP Tunneling mode December 2001
+
+
+7. Author's Address
+
+ 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.net
+
+
+ Tetsuo 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.net
+
+
+ Ken 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.net
+
+
+ Eduard Beier
+ DeTeSystem GmbH
+ Merianstrasse 32
+ D-90409 Nuremberg, Germany
+
+ EMail: Beier@bina.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shimizu, et al. Informational [Page 13]
+
+RFC 3186 MAPOS/PPP Tunneling mode December 2001
+
+
+8. Full Copyright Statement
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shimizu, et al. Informational [Page 14]
+