summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3147.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3147.txt')
-rw-r--r--doc/rfc/rfc3147.txt451
1 files changed, 451 insertions, 0 deletions
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]
+