From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3147.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc3147.txt (limited to 'doc/rfc/rfc3147.txt') diff --git a/doc/rfc/rfc3147.txt b/doc/rfc/rfc3147.txt new file mode 100644 index 0000000..c474ea2 --- /dev/null +++ b/doc/rfc/rfc3147.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group P. Christian +Request for Comments: 3147 Nortel Networks +Category: Informational July 2001 + + + Generic Routing Encapsulation over CLNS Networks + +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. + +Abstract + + This document proposes a method for transporting an arbitrary + protocol over a CLNS (Connectionless Network Service) network using + GRE (Generic Routing Encapsulation). This may then be used as a + method to tunnel IPv4 or IPv6 over CLNS. + +1. Introduction + + RFC 2784 Generic Routing Encapsulation (GRE) [1] provides a standard + method for transporting one arbitrary network layer protocol over + another arbitrary network layer protocol. + + RFC 1702 Generic Routing Encapsulation over IPv4 networks [2] + provides a standard method for transporting an arbitrary network + layer protocol over IPv4 using GRE. + + However no standard method exists for transporting other network + layer protocols over CLNS. This causes lack of interoperability + between different vendors' products as they provide solutions to + migrate from CLNS networks to IP networks. This is a problem + specifically in, but not limited to, the context of management + networks for SONET and SDH networks elements. + + Large networks exist for the purpose of providing management + communications for SONET and SDH network elements. Standards + Bellcore GR-253-CORE [3] and ITU-T G.784 [4] mandate that these + networks are based on CLNS. + + + + + + +Christian Informational [Page 1] + +RFC 3147 Generic Routing Encapsulation over CLNS Networks July 2001 + + + Many vendors have already started to offer SONET and SDH products + that are managed by IP instead of CLNS and a general migration from + CLNS towards IP is anticipated within the industry. + + Part of any migration strategy from CLNS to IP should provide for the + co-existence of both CLNS managed and IP managed network elements in + the same network. + + Such a migration strategy should foresee the need to manage existing + CLNS managed network elements that become isolated by a new IP + network. Such a scenario may be tackled by tunnelling CLNP PDUs over + IP using the existing GRE standard RFC 2784 [1] and informational RFC + 1702 [2]. Networks have already been deployed that use this method. + + Such a migration strategy should also foresee the need to manage new + IP managed network elements that are installed on the far side of + existing CLNS managed network. Such a scenario requires a method for + tunnelling IP over CLNS. + +2. GRE over CLNS advantages + + Using GRE to tunnel IP over CLNS offers some advantages. + + In the absence of a standard for tunnelling IP over CLNS, GRE as + specified in RFC 2784 [1] is the most applicable standard that + exists. + + The move from CLNS to IP comes at a time when IP is itself + migrating from IPv4 to IPv6. GRE defines a method to tunnel any + protocol that has an Ethernet Protocol Type. Therefore by + defining a method for CLNS to transport GRE, a method will then + exist for CLNS to transport any other protocol that has an + Ethernet Protocol Type defined in RFC 1700 [5]. Thus GRE over + CLNS can be used to tunnel both IPv4 and IPv6. + + GRE is already commonly used to tunnel CLNP PDUs over IP and so + using GRE to tunnel IP over CLNS gives a common approach to + tunnelling and may simplify software within network elements that + initiate and terminate tunnels. + + The only disadvantage of using GRE is the extra minimum of four bytes + that will be used between CLNP header and IP payload packet. Given + the large size of CLNP headers this will not make a significant + difference to the performance of any network that has IP over CLNP + PDUs present on it. + + + + + + +Christian Informational [Page 2] + +RFC 3147 Generic Routing Encapsulation over CLNS Networks July 2001 + + +3. Transporting GRE packets over CLNS. + + It is suggested that GRE should be transported over CLNS at the + lowest layer possible, which is as a transport layer protocol over + the network layer. This can be achieved by placing the entire GRE + packet inside a CLNP Data Type PDU (DT PDU) as data payload. + + The GRE packet is a GRE packet as defined in RFC 2784 [1], in other + words GRE header plus payload packet. + + Data payload is the part of a Data PDU that is described as "Data" in + the structure of a Data PDU in ISO/IEC 8473-1 [6]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Christian Informational [Page 3] + +RFC 3147 Generic Routing Encapsulation over CLNS Networks July 2001 + + + For convenience the structure of a Data PDU is reproduced from + ISO/IEC 8473-1 [6] below: + + Octet + ---------------------------------------- + | Network Layer Protocol Identifier | 1 + ---------------------------------------- + | Length Indicator | 2 + ---------------------------------------- + | Version/Protocol Id Extension | 3 + ---------------------------------------- + | Lifetime | 4 + ---------------------------------------- + | SP | MS | E/R | Type | 5 + ---------------------------------------- + | Segment Length | 6,7 + ---------------------------------------- + | Checksum | 8,9 + ---------------------------------------- + | Destination Address Length Indicator | 10 + ---------------------------------------- + | | 11 + | Destination Address | + | | m-1 + ---------------------------------------- + | Source Address Length Indicator | m + ---------------------------------------- + | | m+1 + | Source Address | + | | n-1 + ---------------------------------------- + | Data Unit Identifier | n,n+1 + ---------------------------------------- + | Segment Offset | n+2,n+3 + ---------------------------------------- + | Total Length | n+4,n+5 + ---------------------------------------- + | | n+6 + | Options | + | | p + ---------------------------------------- + | | p+1 + | Data ( GRE packet ) | + | | z + ---------------------------------------- + + + + + + +Christian Informational [Page 4] + +RFC 3147 Generic Routing Encapsulation over CLNS Networks July 2001 + + +4. NSAP selector (N-SEL) value. + + Transport of GRE packets is a new type of Network Service (NS) user. + Different Network Service users are identified by using different + NSAP selector bytes also known as N-SEL bytes. + + This is a similar concept to the use of the IP Protocol Type used in + IP packets. + + Whilst it is not strictly necessary for all vendors to use the same + N-SEL values, they must use the same N-SEL value for it to be + possible for one vendor's CLNS device or network element to initiate + a GRE tunnel which is then terminated on a different vendor's CLNS + device. + + Although N-SEL values (other than zero) are not defined in CLNS/CLNP + standards, some are defined when CLNS is used in SONET networks by + Bellcore GR-253-CORE [3] whilst others are in common use. + + As the IP protocol number for GRE is 47, as defined in RFC 1702 [2], + and as 47 is not commonly used as an N-SEL value, it is suggested + that 47 (decimal) should be used as an N-SEL value to indicate to the + CLNS stack that the Data portion of the Data Type PDU contains a GRE + packet. + + The N-SEL byte should be set to 47 (decimal) in both the source + address and the destination address of the CLNP PDU. + + The N-SEL value of 47 should indicate only that the payload is GRE, + and the device or network element that transmits the PDU should use + the GRE header to indicate what protocol (for example IPv4 or IPv6) + is encapsulated within the GRE packet in conformance with RFC 2784 + [1]. Similarly the device or network element that receives the PDU + should then inspect the GRE header to ascertain what protocol is + contained within the GRE packet in conformance with RFC 2784 [1]. + +5. Segmentation Permitted (SP) value. + + It is recommended that the SP flag in all CLNP PDUs containing GRE + packets should be set. + + If the SP flag is not set, and a CLNP PDU is too large for a + particular link, then a CLNS device or network element will drop the + PDU. The originator of the packet that is inside the GRE packet will + not have visibility of the packet loss or the reason for the packet + loss, and a black hole may form. + + + + + +Christian Informational [Page 5] + +RFC 3147 Generic Routing Encapsulation over CLNS Networks July 2001 + + +6. Interaction with Path MTU Discovery (PMTU), RFC 1191 [7]. + + A tunnel entry point for a GRE tunnel should treat IP packets that + are bigger than the MTU size of the GRE tunnel as per RFC 1191 [7]. + If the oversize IP packet that is about to enter the GRE tunnel does + not have its Don't Fragment (DF) bit set then it should be fragmented + before entering the tunnel. + + If the oversize IP packet that is about to enter the GRE tunnel has + its DF bit set then the packet should be discarded, and an ICMP + unreachable error message (in particular the "fragmentation needed + and DF set" code) should be sent back to the originator of the packet + as described in RFC 1191 [7]. + +7. Security Considerations + + CLNS and GRE do not provide any security when employed in the way + recommended in this document. + + If security is required, then it must be provided by other methods + and applied to the payload protocol before it is transported by GRE + over CLNS. + +8. References + + [1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, + "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. + + [2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing + Encapsulation over IPv4", RFC 1702, October 1994. + + [3] Bellcore Publication GR-253-Core "Synchronous Optical Network + (SONET) Transport Systems: Common Generic Criteria", January 1999 + + [4] ITU-T Recommendation G.784 "Synchronous Digital Hierarchy (SDH) + management", June 1999 + + [5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [6] "Information technology - Protocol for providing the + connectionless-mode network service", ISO/IEC 8473-1, 1994 + + [7] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, + November 1990. + + + + + + +Christian Informational [Page 6] + +RFC 3147 Generic Routing Encapsulation over CLNS Networks July 2001 + + +9. Acknowledgements + + Chris Murton, Paul Fee, Mike Tate for their contribution in writing + this document. + +10. Author's Address + + Philip Christian + Nortel Networks Harlow Laboratories + London Road, Harlow, + Essex, CM17 9NA UK + + EMail: christi@nortelnetworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Christian Informational [Page 7] + +RFC 3147 Generic Routing Encapsulation over CLNS Networks July 2001 + + +11. 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. + + + + + + + + + + + + + + + + + + + +Christian Informational [Page 8] + -- cgit v1.2.3