Valdis;
> > I'm routing based on circuit ID. Current RSVP does not.
>
> Like I said - RSVP is *NOT* circuit based.
You don't have to make the confusion on terminology even worse by
insisting on youres.
Circuit ID is introduced by Noel w.r.t. ATM and you can use
your favourite wording for RSVP
On Sat, 05 Oct 2002 07:38:51 +0859, Masataka Ohta said:
> I'm routing based on circuit ID. Current RSVP does not.
Like I said - RSVP is *NOT* circuit based.
> You misunderstand the problem.
Not in the slightest. I understand RSVP - what I objected to was the
statement that RSVP is circuit bas
Valdis;
> > In this thread, as Noel said:
> > : It's easy to imagine an ATM-like system
> > : in which circuit ID's are global in scope.
> >
> > the circuit ID does not neccessarily imply special routing.
>
> If you're not routing based on circuit ID, why are you bothering to have one?
I'm rou
On Sun, 29 Sep 2002 10:11:13 +0859, Masataka Ohta said:
> In this thread, as Noel said:
> : It's easy to imagine an ATM-like system
> : in which circuit ID's are global in scope.
>
> the circuit ID does not neccessarily imply special routing.
If you're not routing based on circuit ID, why are yo
Valdis;
> > RSVP establishes the per-flow state before the packets can flow.
> >
> > It is just a minor engineering decision to allow optional circuit
> > switched service over a best-effort-capable network.
>
> 1) I wasn't aware that RSVP caused packets to be routed according to
> a flow ID co
Lixia;
> >> RSVP establishes the per-flow state before the packets can flow.
>
> I missed Ohta Son's original post, thanks to Valdis for catching this
> incorrect statement.
>
> IP packets can flow anytime.
Fixing your statement:
IP packets can be forwarded anytime.
To say "flow" on
Lets just get some FACTS straight out
On 9/28/02 3:29 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> On Sun, 29 Sep 2002 06:20:59 +0859, Masataka Ohta said:
>
>> RSVP establishes the per-flow state before the packets can flow.
I missed Ohta Son's original post, thanks to Valdis for catch
On Sun, 29 Sep 2002 06:20:59 +0859, Masataka Ohta said:
> RSVP establishes the per-flow state before the packets can flow.
>
> It is just a minor engineering decision to allow optional circuit
> switched service over a best-effort-capable network.
1) I wasn't aware that RSVP caused packets to b
Noel;
> > From: Caitlin Bestler <[EMAIL PROTECTED]>
>
> > Given the source interface, the *meaning* of an IP header is not
> > supposed to be dependent on the routing tables. ..
> > By contrast, the meaning of an ATM circuit is dependent on the context
> > in which it was es
> From: Caitlin Bestler <[EMAIL PROTECTED]>
> Given the source interface, the *meaning* of an IP header is not
> supposed to be dependent on the routing tables. ..
> By contrast, the meaning of an ATM circuit is dependent on the context
> in which it was established. There is
On 9/26/02, Lloyd Wood wrote:
>On Thu, 26 Sep 2002, Caitlin Bestler wrote:
>
>>
>> So, as originally proposed an IP fragment is a fully
>> self-routed L3 datagram.
>
>well, not self-routed; you need routing state. I don't
>think the difference between routing table state and
>circuit-switched sta
At 12:35 PM 9/26/2002 -0500, Caitlin Bestler wrote:
>However, in the de facto world of merged L3/L4 routing
>(with NATs, load balancers, etc.) it is dependent on state
>information and hence is not a datagram.
any interconnection is an end station issue; the only router that cares
about it is th
On 9/26/02, Lloyd Wood wrote:
>On Wed, 25 Sep 2002, Fred Baker wrote:
>
>> At 01:12 PM 9/25/2002 +0100, Lloyd Wood wrote:
>> >A datagram is self-describing; full source and
>> >destination. A fragment (IPv4 fragment) may not be.
>>
>> you sure? take a GOOD look at RFC 791... It is
>> completely s
Hello Lloyd,
Wednesday, September 25, 2002, 2:12:13 PM, you wrote:
>> >the following distinction : "a datagram is the data unit before
>> >fragmentation" ; "a packet is a piece of a fragmented datagram".
>>
>> :^)
>>
>> A fragment of a datagram is itself a datagram; after you re-assemble them,
>
At 01:12 PM 9/25/2002 +0100, Lloyd Wood wrote:
>A datagram is self-describing; full source and destination. A fragment
>(IPv4 fragment) may not be.
you sure? take a GOOD look at RFC 791... It is completely self-describing
in terms of getting itself there and where it belongs in the reassembled
Lloyd;
> > At 05:44 PM 9/24/2002 +0200, TOMSON ERIC wrote:
> > >Last, while I definitely, clearly prefer calling Layer 2 data units
> > >"FRAMES", I sometimes [over-]simplify the terminology of Layer 3 by making
> > >the following distinction : "a datagram is the data unit before
> > >fragmentati
At 05:44 PM 9/24/2002 +0200, TOMSON ERIC wrote:
>Last, while I definitely, clearly prefer calling Layer 2 data units
>"FRAMES", I sometimes [over-]simplify the terminology of Layer 3 by making
>the following distinction : "a datagram is the data unit before
>fragmentation" ; "a packet is a piec
As a trainer, I like to tell that the word DATAGRAM is built on the same basis as the
word TELEGRAM. It's actually a kind of "telegram-of-data".
I also usually explain that Packet Switching relies on two different modes : DATAGRAM
vs VIRTUAL CIRCUITS. The datagram mode is mainly connectionless
18 matches
Mail list logo
