RFC relevance of encapsulation

As per Relevance of the word encapsulation, we have this rfc below:

Network Working Group P.
Request for Comments: 3147 Nortel
Category: Informational July 2001

Generic Routing Encapsulation over CLNS

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (2001). All Rights Reserved

This document proposes a method for transporting an
protocol over a CLNS (Connectionless Network Service) network
GRE (Generic Routing Encapsulation). This may then be used as
method to tunnel IPv4 or IPv6 over CLNS

1.

RFC 2784 Generic Routing Encapsulation (GRE) [1] provides a
method for transporting one arbitrary network layer protocol
another arbitrary network layer protocol

RFC 1702 Generic Routing Encapsulation over IPv4 networks [2]
provides a standard method for transporting an arbitrary
layer protocol over IPv4 using GRE

However no standard method exists for transporting other
layer protocols over CLNS. This causes lack of
between different vendors' products as they provide solutions
migrate from CLNS networks to IP networks. This is a
specifically in, but not limited to, the context of
networks for SONET and SDH networks elements

Large networks exist for the purpose of providing
communications for SONET and SDH network elements.
Bellcore GR-253-CORE [3] and ITU-T G.784 [4] mandate that
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
that are managed by IP instead of CLNS and a general migration
CLNS towards IP is anticipated within the industry

Part of any migration strategy from CLNS to IP should provide for
co-existence of both CLNS managed and IP managed network elements
the same network

Such a migration strategy should foresee the need to manage
CLNS managed network elements that become isolated by a new
network. Such a scenario may be tackled by tunnelling CLNP PDUs
IP using the existing GRE standard RFC 2784 [1] and informational
1702 [2]. Networks have already been deployed that use this method

Such a migration strategy should also foresee the need to manage
IP managed network elements that are installed on the far side
existing CLNS managed network. Such a scenario requires a method
tunnelling IP over CLNS

2. GRE over CLNS

Using GRE to tunnel IP over CLNS offers some advantages

In the absence of a standard for tunnelling IP over CLNS, GRE
specified in RFC 2784 [1] is the most applicable standard
exists

The move from CLNS to IP comes at a time when IP is
migrating from IPv4 to IPv6. GRE defines a method to tunnel
protocol that has an Ethernet Protocol Type. Therefore
defining a method for CLNS to transport GRE, a method will
exist for CLNS to transport any other protocol that has
Ethernet Protocol Type defined in RFC 1700 [5]. Thus GRE
CLNS can be used to tunnel both IPv4 and IPv6.

GRE is already commonly used to tunnel CLNP PDUs over IP and
using GRE to tunnel IP over CLNS gives a common approach
tunnelling and may simplify software within network elements
initiate and terminate tunnels

The only disadvantage of using GRE is the extra minimum of four
that will be used between CLNP header and IP payload packet.
the large size of CLNP headers this will not make a
difference to the performance of any network that has IP over
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
lowest layer possible, which is as a transport layer protocol
the network layer. This can be achieved by placing the entire
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
words GRE header plus payload packet

Data payload is the part of a Data PDU that is described as "Data"
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
ISO/IEC 8473-1 [6] below

----------------------------------------
| 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+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+1
| Data ( GRE packet ) |
| |
----------------------------------------

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
NSAP selector bytes also known as N-SEL bytes

This is a similar concept to the use of the IP Protocol Type used
IP packets

Whilst it is not strictly necessary for all vendors to use the
N-SEL values, they must use the same N-SEL value for it to
possible for one vendor's CLNS device or network element to
a GRE tunnel which is then terminated on a different vendor's
device

Although N-SEL values (other than zero) are not defined in CLNS/
standards, some are defined when CLNS is used in SONET networks
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
that 47 (decimal) should be used as an N-SEL value to indicate to
CLNS stack that the Data portion of the Data Type PDU contains a
packet

The N-SEL byte should be set to 47 (decimal) in both the
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
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
should then inspect the GRE header to ascertain what protocol
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
packets should be set

If the SP flag is not set, and a CLNP PDU is too large for
particular link, then a CLNS device or network element will drop
PDU. The originator of the packet that is inside the GRE packet
not have visibility of the packet loss or the reason for the
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
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
not have its Don't Fragment (DF) bit set then it should be
before entering the tunnel

If the oversize IP packet that is about to enter the GRE tunnel
its DF bit set then the packet should be discarded, and an
unreachable error message (in particular the "fragmentation
and DF set" code) should be sent back to the originator of the
as described in RFC 1191 [7].

7. Security

CLNS and GRE do not provide any security when employed in the
recommended in this document

If security is required, then it must be provided by other
and applied to the payload protocol before it is transported by
over CLNS

8.

[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
Encapsulation over IPv4", RFC 1702, October 1994.

[3] Bellcore Publication GR-253-Core "Synchronous Optical
(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
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.

Chris Murton, Paul Fee, Mike Tate for their contribution in
this document

10. Author's

Philip
Nortel Networks Harlow
London Road, Harlow
Essex, CM17 9NA

EMail: christi@nortelnetworks.

Christian Informational [Page 7]

RFC 3147 Generic Routing Encapsulation over CLNS Networks July 2001

11. Full Copyright

Copyright (C) The Internet Society (2001). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Christian Informational [Page 8]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX