rfc3034.txt

最新的RFC

RFC 3034            Label Switching with Frame Relay        January 2001


7.3   LDP messages specific to Frame Relay

   The Label Distribution Protocol [LDP] messages exchanged between two
   Frame Relay "LDP-peer" LSRs may contain Frame Relay specific
   information such as:

   "Frame Relay Label Range":

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved    |Len|               Minimum DLCI                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved        |               Maximum DLCI                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   with the following fields:

   Reserved
      This fields are reserved.  They must be set to zero on
      transmission and must be ignored on receipt.

   Len
      This field specifies the number of bits of the DLCI.  The
      following values are supported:

          Len  DLCI bits

          0     10
          2     23

      Len values 1 and 3 are reserved for future use.

   Minimum DLCI
      This 23 bit field is the binary value of the lower bound of a
      block of Data Link Connection Identifiers (DLCIs) that is
      supported by the originating FR-LSR.  The Minimum DLCI should be
      right justified in this field and the preceding bits should be set
      to 0.

   Maximum DLCI
      This 23 bit field is the binary value of the upper bound of a
      block of Data Link Connection Identifiers (DLCIs) that is
      supported by the originating FR-LSR.  The Maximum DLCI should be
      right justified in this field and the preceding bits should be set
      to 0.





Conta, et al.               Standards Track                    [Page 19]

RFC 3034            Label Switching with Frame Relay        January 2001


   "Frame Relay Merge":

          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         | Reserved    |M|
         +-+-+-+-+-+-+-+-+

      with the following fields:

   Merge
      One bit field that specifies the merge capabilities of the FR-LSR:

      Value                  Meaning

        0                    Merge NOT supported
        1                    Merge supported

      A FR-LSR that supports VC merging MUST ensure that fragmented
      frames from distinct incoming DLCIs are not interleaved on the
      outgoing DLCI.

   Reserved
      This field is reserved.  It must be set to zero on transmission
      and must be ignored on receipt.

   and "Frame Relay Label":

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved    |Len|                       DLCI                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   with the following fields:

   Reserved
      This field is reserved.  It must be set to zero on transmission and
      must be ignored on receipt.

   Len
      This field specifies the number of bits of the DLCI.  The following
      values are supported:

          Len  DLCI bits

          0     10
          2     23




Conta, et al.               Standards Track                    [Page 20]

RFC 3034            Label Switching with Frame Relay        January 2001


      Len values 1 and 3 are reserved for future use.

   DLCI
      The binary value of the Frame Relay Label.  The significant number
      of bits (10 or 23) of the label value are to be encoded into the
      Data Link Connection Identifier (DLCI) field when part of the
      Frame Relay data link header (see Section 4.).

8.  Security Considerations

   This section looks at the security aspects of:

      (a) frame traffic,

      (b) label distribution.

   MPLS encapsulation has no effect on authenticated or encrypted
   network layer packets, that is IP packets that are authenticated or
   encrypted will incur no change.

   The MPLS protocol has no mechanisms of its own to protect against
   misdirection of packets or the impersonation of an LSR by accident or
   malicious intent.

   Altering by accident or forgery an existent label in the DLCI field
   of the Frame Relay data link layer header of a frame or one or more
   fields in a potentially following label stack affects the forwarding
   of that frame.

   The label distribution mechanism can be secured by applying the
   appropriate level of security to the underlying protocol carrying
   label information - authentication or encryption - see [LDP].

9.  Acknowledgments

   The initial version of this document was derived from the Label
   Switching over ATM document [ATM].

   Thanks for the extensive reviewing and constructive comments from (in
   alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller,
   Eric Rosen.  Also thanks to George Swallow for the suggestion to use
   null encapsulation, and to Eric Gray for his reviewing.

   Also thanks to Nancy Feldman and Bob Thomas for their collaboration
   in including the LDP messages specific to Frame Relay LSRs.






Conta, et al.               Standards Track                    [Page 21]

RFC 3034            Label Switching with Frame Relay        January 2001


10.  References

   [MIFR]  Bradley, T., Brown, C. and A. Malis, "Multiprotocol
           Interconnect over Frame Relay", RFC 2427, September 1998.

   [ARCH]  Rosen, E., Callon, R. and A. Vishwanathan, "Multi-Protocol
           Label Switching Architecture", RFC 3031, January 2001.

   [LDP]   Andersson, L., Doolan, P., Feldman, N., Fredette, A. and R.
           Thomas, "Label Distribution Protocol", RFC 3036, January
           2001.

   [STACK] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow,
           G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC
           3032, January 2001.

   [ATM]   Davie, B., Lawrence, J., McCloghrie, M., Rosen, E., Swallow,
           G., Rekhter, Y., and P. Doolan, "Use of Label Switching with
           ATM", RFC 3035, January 2001.

   [ITU]   International Telecommunications Union, "ISDN Data Link Layer
           Specification for Frame Mode Bearer Services", ITU-T
           Recommendation Q.922, 1992.

   [FRF]   Frame Relay Forum, User-to-Network Implementation Agreement
           (UNI), FRF 1.1, January 19, 1996.

























Conta, et al.               Standards Track                    [Page 22]

RFC 3034            Label Switching with Frame Relay        January 2001


11.  Authors' Addresses

   Alex Conta
   Transwitch Corporation
   3 Enterprise Drive
   Shelton, CT 06484

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


   Paul Doolan
   Ennovate Networks
   60 Codman Hill Rd
   Boxborough MA 01719

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


   Andrew G. Malis
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   USA

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






















Conta, et al.               Standards Track                    [Page 23]

RFC 3034            Label Switching with Frame Relay        January 2001


12.  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.



















Conta, et al.               Standards Track                    [Page 24]