Subject: RE: [Isis-wg] OSI ??

From: Les Ginsberg <[email-masked]>
Date: Wed, 8 Aug 2001 12:51:20 -0700

Ken -

This is a good summary. A few minor corrections/clarifications.

As has been mentioned in other responses, but is worth reemphasis, IS-IS
PDUs are NOT encapsulated in CLNP PDUs as your text states below. IS-IS (as
well as ES-IS) are run directly over the link layer. They can be
de-multiplexed from CLNP PDUs by the initial byte in the NPDU - which is a
Network Layer Protocol Identifier(NLPID) in all three cases:

   CLNP - 0x81(129)
   ES-IS - 0x82(130)
   IS-IS - 0x83(131)

As far as the SEL byte is concerned, it should be intuitively thought of as
an ID for the network layer user. The NSAP associated with a network layer
user most often bears a close relationship to the network entity title(NET)
assigned to the Layer 3 protocol. (Although strict interpretation of ISO
addressing allows for a user NSAP to bear virtually no relationship to the
NET this is not commonly encountered and is, frankly, too bizarre to be
discussed.)

So, if the NET assigned consisted of:

   Area address:  49
   System ID:     1111.2222.3333
   Selector:      00 (Always)

then a network layer user on that box would have an NSAP which differed only
in the selector (i.e. 49.1111.2222.3333.xx).

There is no set of universally assigned values for the SEL byte. SEL's are
assigned within an administrative domain or by industry agreement. For
example, SONET(Bellcore/Telcordia) specifications assigned:

   01 - OSI transport
   AF - TL1 Address Resolution Protocol (I think I remember that value
correctly...)

In order for OSI transport layers to successfully communicate within a SONET
domain, these values would have to be used consistently.

In this context, DEC's use of the selector byte to direct NPDUs to the
appropriate transport layer is quite appropriate and consistent with OSI
addressing semantics.

   Les

> 
> Hi,
> 
> 	Let me try to explain the difference between CLNS 
> (Connection-Less Network
> Service) and CONS (Connection-Oriented Network Service). 
> Furthermore, I will
> attempt to explain their use with IS-IS (OSI only) and I will 
> then attempt
> to tie their use with Integrated IS-IS (Dual OSI and IP).
> 
> 	One must remember that OSI was conceived in the 1980s 
> by Digital with its
> primary reason being to increase DECnet Phase IV address space. Thus,
> Digital designed DECnet Phase V, which in turn spawned the 
> better part of
> OSI. In the 1980s the predominate LAN technology was Ethernet and the
> predominate WAN technology was X.25. Ethernet circuits are 
> considered to be
> Connection-Less, while X.25 networks are considered to be
> Connection-Oriented.
> 
> The difference being that when an ES wants to transmit a data 
> packet across
> an Ethernet, it simply sends it to the destination or to the 
> default router.
> There is no need to establish a prior connection because all MTU sizes
> should be the same and there is no need to negotiate 
> flow-control below the
> transport layer. However, on an X.25 network, an ES or IS 
> must setup the
> connection to the remote DTE prior to transmission of data 
> packets. X.25 has
> many negotiable options for data transfer, there are really 
> no defaults, per
> say!
> 
> 	So, CONS was employed as a mechanism for communicating 
> with ISO-8208 X.25
> packet switch networks to facilitate call setup, parameter 
> negotiation,
> circuit maintenance and call teardown. SNDCF (Sub-Network Dependent
> Convergence Functions) are utilized by the OSI network layer 
> to communicate
> with the X.25 PLP (Packet Level Protocol) for execution of these DTE
> functions. Through this CONS mechanism, we can setup, 
> maintain and teardown
> SVCs between X.25 DTEs.
> 
> Furthermore, since X.25 already possessed a method for 
> guaranteed delivery
> (LAPB - Link Access Procedure Balanced) at the datalink 
> DTE<>DCE and packet
> sequencing at the X.25 network layer DTE<cloud>DTE, there is 
> no need to
> sequence packets at the transport layer when using a CONS 
> network. So, most
> applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport
> mechanism across CONS networks. TP0 and TP2 are much like UDP.
> 
> 	Ethernet on the other hand does not require call 
> establishment prior to
> transport of data. So, CLNS is used to communicate across this type of
> network. Since there is no guaranteed delivery mechanism with Ethernet
> (Broadcast circuits for that matter), we need to make sure we use a
> higher-layer to guarantee delivery of packets. This is where 
> OSI TP4 comes
> into play. OSI TP4 is much like TCP in that it sequences packets and
> basically guarantees their delivery.
> 
> 	Now, how does this tie into CLNP (Connection-Less 
> Network Protocol) and the
> format of OSI packets? Well, both CONS and CLNS networks 
> transfer OSI data
> in CLNP packet formats.
> 
> On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3
> formatted ethernet frames. The data portion of an IEEE 802.3 
> frame, which is
> carrying OSI data, must have as its first octet a value of 
> 128 (81 hex) =
> OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 
> hex) IS-IS
> control packet. This first octet is referred to as the NLPID 
> (Network Layer
> Protocol Identifier) for ES-IS and OSI data and error packets 
> and as IRPD
> (Intradomain Routing Protocol Discriminator) for IS-IS 
> control packets. This
> is how the packet is passed up the stack to the proper 
> network layer entity.
> 
> 	On a CONS X.25 network, OSI packets are exchanged as 
> USER DATA contained
> within the X.25- PLP. Again, the first octet in the user data 
> portion of an
> X.25 packet, must have as its first octet a value of 128 (81 
> hex) = OSI data
> packet. ES-IS and IS-IS are not normally run over an X.25 
> circuit. Instead
> most implementations of OSI/X.25 only allow for SVCs or DED 
> (Dynamically
> Established Datalinks). In most cases, the OSI network layer 
> uses X.121
> addresses (X.25 DTE addresses), extracted from X.121 
> formatted NSAPs to
> signal the correct DTE for the call setup to the remote DTE. 
> Another reason
> for not running ES-IS or IS-IS over an X.25 network is 
> because some PSNs
> charge by the packet. Static routes are much cheaper.
> 
> 	An IS-IS OSI-only router will exchange IS-IS and ES-IS 
> control data
> encapsulated in a CLNP packet. An IS-IS OSI-only router will 
> also forward
> OSI data in a CLNP packet. An Integrated IS-IS IP-only router 
> will exchange
> IS-IS control data encapsulated in a CLNP packet. An IS-IS 
> IP-only router
> will forward IP data in an IP encapsulated packet. It will 
> NOT exchange any
> ES-IS control data nor will it forward any OSI data, just IP 
> data in its
> native format. An Integrated IS-IS Dual router will act as 
> both an OSI-only
> router and IP-only router.
> 
> 	Finally, the SEL (Selector) portion of an NSAP, though 
> not defined by any
> ISO docs in this manner, was used by Digital to signal the 
> Network layer of
> a DECnet Phase V system to send this packet to either the NSP 
> (DECnet Phase
> IV transport) or OSI Transport.
> 
> Hope this helps?
> 
> Cheers,
> Ken Larmer
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Wed, 08 Aug 2001 18:14:54 -0400

>appropriate transport layer is quite appropriate and consistent with OSI

Yes, although it doesn't permit many of the capabilities offered by
these protocols, such as multiplexing CLTP and TP2-4 on the same
CONS connection, or negotiating the transport protocol from
TP2 to TP0.

Anyway, while it's allowable to use the NSEL to address a
particular transport protocol engine, it's not necessary.
TP0, TP1, TP2, TP3, TP4, and CLTP can be implemented in the
same protocol engine and share the same NSEL.

Jeff