rfc1526.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1526              System Identifiers for TUBA         September 1993


   whether the individual address is globally or locally assigned.  In
   these circumstances, the subtype bits are "don't care", and the
   system identifier shall be interpreted as a 48-bit, globally unique
   identifier assigned from the IEEE 802 committee (an ethernet
   address).  The remaining bits in octet 1, together with octets 2 and
   3 are the vendor code or OUI (organizationally unique identifier), as
   illustrated in Figure 4.  The ID is encoded in IEEE 802 canonical
   form (low order bit of low order hex digit of leftmost octet is the
   first bit transmitted).

   Octet 1     Octet 2     Octet 3     Octet 4     Octet 5   Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| VVVV VV00 | VVVV VVVV | VVVV VVVV | SSSS SSSS | SSSS SSSS | SSSS SSSS |
+-----------+-----------+-----------+-----------+-----------+-----------+

|------------vendor code -----------|--------station code---------------|

                Figure 4. IEEE 802 form of system identifier

4.  Embedded IP Address as System Identifier

   To distinguish 48-bit IEEE 802 addresses used as system identifiers
   from other forms of globally admininistered system identifiers, the
   qualifer bit M shall be set to 1. The correct interpretation of the M
   bit set to 1 should be, "this can't be an IEEE 802 multicast address,
   since use of multicast addresses is by convention illegal, so it must
   be some other form of system identifier". The subtype (TT) bits
   illustrated in Figure 3 thus become relevant.

   When the subtype bits (TT) are set to a value of 0, the system
   identifier contains an embedded IP address. The remainder of the 48-
   bit system identifier is encoded as follows. The remaining nibble in
   octet 1 shall be set to zero.  Octet 2 is reserved and shall be set
   to a pre-assigned value (see Figure 5).  Octets 3 through 6 shall
   contain a valid IP address, assigned by IANA.  Each octet of the IP
   address is encoded in binary, in internet canonical form, i.e., the
   leftmost bit of the network number first.

   Octet 1     Octet 2     Octet 3     Octet 4     Octet 5   Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| 0000 0001 | 1010 1010 | aaaa aaaa | bbbb bbbb | cccc cccc | dddd dddd |
+-----------+-----------+-----------+-----------+-----------+-----------+

|-len&Type--|--reserved-|---------IP address----------------------------|

                Figure 5. Embedded IP address as system identifier





Piscitello                                                      [Page 5]

RFC 1526              System Identifiers for TUBA         September 1993


   As an example, the host "eve.bellcore.com = 128.96.90.55" could retain
   its IP address as a system identifier in a TUBA/CLNP network. The
   encoded ID is illustrated in Figure 6.


   Octet 1     Octet 2     Octet 3     Octet 4     Octet 5   Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| 0000 0001 | 1010 1010 | 1000 0000 | 0110 0000 | 0101 1010 | 0011 0111 |
+-----------+-----------+-----------+-----------+-----------+-----------+

|-len&Type--|--reserved-|---------IP address----------------------------|

                Figure 6. Example of IP address encoded as ID

H 2 "Other forms of System Identifiers"

   To allow for the future definition of additional 6-octet system
   identifiers, the remaining subtype values are reserved.

   It is also possible to identify system identifiers with lengths other
   than 6 octets. Communities who wish to use 8 octet identifiers (for
   example, embedded E.164 international numbers for the ISDN ERA) must
   use a GOSIP/ANSI DSP format that allows for the specification of 2
   additional octets in the ID field, perhaps at the expense of the
   "Rsvd" fields; this document recommends that a separate Domain Format
   Indicator value be assigned for such purposes; i.e., a DFI value that
   is interpreted as saying, among other things, "the system identifier
   encoded in this DSP is 64-bits/8 octets. The resulting ANSI/GOSIP DSP
   formats under such circumstances are illustrated in Figure 7:






















Piscitello                                                      [Page 6]

RFC 1526              System Identifiers for TUBA         September 1993


               ______________
               |<--_IDP_-->_|______________________________
               |AFI_|__IDI__|____________<--_DSP_-->_______|
               |_39_|__840__|DFI_|_ORG_|RD_|Area_|_ID_|Sel_|
        octets |_1__|___2___|_1__|__3__|_2_|__2__|_8__|_1__|

        Figure 7a: ANSI NSAP address format for DCC=840, DFI=foo

               _______________
               |<--__IDP_-->_|___________________________________
               |AFI_|__IDI___|___________<--_DSP_-->____________|
               |_47_|__0005__|DFI_|AA_|_RD_|Area_|ID_|Sel_|
        octets |_1__|___2____|_1__|_3_|_2__|_2___|_8_|_1__|

                      IDP   Initial Domain Part
                      AFI   Authority and Format Identifier
                      IDI   Initial Domain Identifier
                      DSP   Domain Specific Part
                      DFI   DSP Format Identifier
                      AA    Administrative Authority
                      RD    Routing Domain Identifier
                      Area  Area Identifier
                      ID    System Identifier
                      SEL   NSAP Selector

       Figure 7b: GOSIP Version 2 NSAP structure, DFI=bar

   Similar address engineering can be applied for those communities who
   wish to have shorter system identifiers; have another DFI assigned,
   and expand the reserved field.

5.  Conclusions

   This proposal should debunk the "if it's 48-bits, it's gotta be an
   ethernet address" myth. It demonstrates how IP addresses may be
   encoded within the 48-bit system identifier field in a compatible
   fashion with IEEE 802 addresses, and offers guidelines for those who
   wish to use system identifiers other than those enumerated here.













Piscitello                                                      [Page 7]

RFC 1526              System Identifiers for TUBA         September 1993


6.  References

   [1] Callon, R., Gardner, E., and R. Colella, "Guidelines for OSI NSAP
       Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, June
       1991.

   [2] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
       Proposal for Internet Addressing and Routing", RFC 1347, DEC,
       June 1992.

   [3] ISO, "Intradomain routing protocol for use in conjunction with
       ISO 8473, Protocol for providing the OSI connectionless network
       service", ISO 10589.

   [4] ISO, End-system and intermediate-system routing protocol for use
       in conjunction with ISO 8473, Protocol for providing the OSI
       connectionless network service, ISO 9542.

   [5] ISO, "End-system and intermediate-system routing protocol for use
       in conjunction with ISO 8473, Protocol for providing the OSI
       connectionless network service.  Amendment 1: Dynamic Discovery
       of OSI NSAP Addresses End Systems", ISO 9542/DAM1.

   [6] Perlman, R., "Interconnections: Bridges and Routers", Addison-
       Wesley Publishers, Reading, MA. 1992.

7.  Security Considerations

   Security issues are not discussed in this memo.

8.  Author's Address

   David M. Piscitello
   Bell Communications Research
   NVC 1C322
   331 Newman Springs Road
   Red Bank, NJ 07701

   EMail: [e-mail]












Piscitello                                                      [Page 8]