Re: Tangent for B-LLI (was Re: Comments on ipv6nd-02.txt )

Bryan Gleeson <bryang@cisco.com> Mon, 13 May 1996 20:54 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21745; 13 May 96 16:54 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21739; 13 May 96 16:54 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa13866; 13 May 96 16:54 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id QAA09167; Mon, 13 May 1996 16:53:32 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id QAA01804 for ip-atm-out; Mon, 13 May 1996 16:38:31 -0400 (EDT)
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id QAA01795 for <ip-atm@nexen.com>; Mon, 13 May 1996 16:38:28 -0400 (EDT)
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id QAA08931 for <ip-atm@nexen.com>; Mon, 13 May 1996 16:38:26 -0400 (EDT)
Received: from bgleeson-ss20.cisco.com (bgleeson-ss20.cisco.com [171.69.193.208]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id NAA29018; Mon, 13 May 1996 13:41:24 -0700
Received: (bgleeson@localhost) by bgleeson-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) id NAA14385; Mon, 13 May 1996 13:38:22 -0700
Date: Mon, 13 May 1996 13:38:22 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bryan Gleeson <bryang@cisco.com>
Message-Id: <199605132038.NAA14385@bgleeson-ss20.cisco.com>
To: gja@bellcore.com
Subject: Re: Tangent for B-LLI (was Re: Comments on ipv6nd-02.txt )
Cc: ip-atm@nexen.com
X-Orig-Sender: owner-ip-atm@nexen.com
Precedence: bulk
X-Info: Submissions to ip-atm@nexen.com
X-Info: [Un]Subscribe requests to majordomo@nexen.com
X-Info: Archives via http://cell-relay.indiana.edu/cell-relay/archives/IPATM/IPATM.html

Grenville,

>
>I thought we'd gone over this a year or so ago :-)
>

I thought I'd try again :-)

>>>For example one protocol may use multiple data plane encapsulations (e.g.
>>>a Classical IP which uses both LLC/SNAP and "null" encapsulated VCs).
>>>The same data plane encapsulation may be used by different protocols
>>>(e.g. Classical IP, NHRP, MPOA, LANE V2.0, etc may all use LLC/SNAP
>>>encapsulation). As the mapping is many to many the BLLI just doesn't do a
>>>good job of identifying signalling user entities. 
>
>I don't think your conclusion in this example is justifiable. The
>B-LLI does exactly what it is required to do - identify the AAL User
>that will take AAL_SDUs immediately after AAL reassembly.
>
>For Classical IP there can be two types of AAL Users - an IP layer
>itself ("null" encapsulation), or an LLC entity (further demuxing
>arriving AAL_SDUs based on the LLC/SNAP header).
>
>If an LLC entity is identified as the immediate AAL User to
>which AAL_SDUs are passed, and there was no additional B-LLI
>or B-HLI field in the call that pre-defined the ultimate
>destination of the AAL_SDU's contents, then the LLC entity does
>the demuxing of IP, NHRP, LANE, MARS, packets. The various
>higher layer protocols are then simply clients of the LLC
>entity, and are insulated from the LLC entities interactions
>with the AAL layer and UNI instance. 


I agree with everything you have said up to here, but not with
the last sentence ....

>I think the B-LLI does
>exactly what is needed for identifying 'signalling user entities'.


B-LLI does a splendid job of identifying the AAL user on the data
place. My point was that this may be different from the control 
plane user entity, and that using the B-LLI to try and identify
this is a mistake. The Classical IP entity on a machine is what
you want to identify when placing a call to it, and SEL allows
you to do that. A single Classical IP entity may support multiple
data plane encapsulations, each of which is identified by a distinct
B-LLI. Thus you may have two users on the data plane, but one on the
control plane. The VCCs may be established, maintained and aged out
independently of the data plane encapsulation.

It is like identifying people in a room on the basis of the  
language they speak. If I know there is only one person that
speaks German then I can identify him as the "guy who speaks
German". If there are multiple people who speak German then
I need another mechanism. Ignoring for the moment that two
people may have the same name, I can address people by name -
Franz or Johan or whatever. Note that Franz may be multilingual 
and may be able to speak French as well, so identifying people
on the basis of the language(s) they speak leads to ambiguities.
Of course to be able to do anything useful we would need to
be able to speak a common language. In my case I could try to 
use my schoolboy German to negotiate the use of English,
assuming that Franz spoke English too - and this would be the
equivalent of B-LLI negotiation. (assuming the conversation
wasn't just to be - Wo ist die Bier Keller, bitte :-)

Bryan