rfc3186.txt

RFC 的详细文档！


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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Tetsuo Kawano
   NTT Network Innovation Laboratories,
   3-9-11, Midori-cho Musashino-shi
   Tokyo  180-8585  Japan

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Ken Murakami
   NTT Network Innovation Laboratories,
   3-9-11, Midori-cho Musashino-shi
   Tokyo  180-8585  Japan

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Eduard Beier
   DeTeSystem GmbH
   Merianstrasse 32
   D-90409 Nuremberg, Germany

   EMail: [e-mail]













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]