APC-1304 Posted to FTP site (ReplacementFor)

Dave Lindbergh lindbergh at ITU.CH
Thu Aug 28 21:42:09 EDT 1997


Hussein,

Reading carefully over your proposed text, I conclude that it
is not strictly necessary for the receiver to get OLC before
it requests a bigger RSVP reservation.  The thing that tells
the receiver to do this is _not_ OLC, but is the RSVP advertisement.

So if I'm correct about that (I might not be), then your proposal
is really an optimization of the procedure rather than a correction,
in that it saves a round-trip by doing some of the RSVP and H.245
stuff in parallel.

However, I'd prefer strongly to keep the example in the appendix
simple; there is nothing to prevent implementors from being more
clever and saving some time as you suggest.  But I think it's
simpler for the reader if all the RSVP operations are in a
single step, if it will in fact work correctly that way.

So I'd like to keep the example as it was before; the only change
I'll make is to use the word "advertise" instead of "request".

If this is wrong, we can fix it in Sunriver.

I hope to see you there.

--Dave L.


At 06:45 PM 8/26/97 -0700, Hussein Salama wrote:
>Dave,
>
>I looked at your ReplacementFor document. In RSVP the transmitter first
>advertizes the reservation parameters, then the receiver requests
>reservations based on the transmitter's advertizements. Based on that, I
>suggest the modifications below to the example you gave on page 2.
>
>My understanding is that the example is based on the assumption that
>both the transmitter and the receiver will reuse the same port numbers
>of the original channel in the ReplacementFor channel.
>
>Example
>=======
>
>Suppose LC 723 is open, carrying G.723.1 audio, and it is desired to
>switch to G.711 (on LC 711), but the receiver has a capability for only
>one audio channel.  The replacementFor mechanism may be used by the
>transmitter to effect a seamless mode change as follows:
>
>1. Only for the case of H.323 using RSVP: since the new channel will
>require more bandwidth (64 kbps) than the existing channel (6.4 kbps),
>the transmitter advertizes a larger RSVP bandwidth.
>
>2. The transmitter sends OpenLogicalChannel for the new LC 711,
>including the replacementFor parameter, referring to the existing LC
>723.
>
> This tells the receiver that LC 711 is a replacement for LC 723, and
>that LC 711 will never carry traffic simultaneously with LC 723.
>
>3. While continuing to decode G.723.1 from LC 723, the receiver prepares
>for a seamless switch to decoding G.711.
>
>Such preparation might include loading appropriate decoder software.
>
>Only for the case of H.323 using RSVP: the receiver requests and
>receives acknowledgment for a larger RSVP bandwidth reservation.
>
>When the receiver has completed preparations to accept the G.711 audio
>stream, it responds with OpenLogicalChannelAck for LC 711.
>
>4. The transmitter stops sending G.723 audio on LC 723 and seamlessly
>begins sending G.711 audio on LC 711.
>
>5. The transmitter immediately sends CloseLogicalChannel for LC 723, as
>this LC is no longer carrying any traffic, and is no longer needed.
>
>6. Only for the case of H.323 using RSVP, if the new channel requires
>less bandwidth than the original channel, the transmitter advertizes the
>smaller RSVP bandwidth after it sends the CloseLogicalChannel message,
>and the receiver requests a smaller RSVP bandwidth reservation after it
>receives the CloseLogicalChannel message (does
>not apply in this example).
>
>
>
>Does this sound right?
>
>Hussein
>
>
>
>Dave Lindbergh wrote:
>>
>> At 03:48 PM 8/26/97 -0700, Hussein Salama wrote:
>> >Dave,
>> >
>> >Your APC covers the ReplacementFor function. It seems to me that from an
>> >RSVP pont of view, making reservations for ReplacementFor channels is
>> >the same as making reservations for new channels. So I see no need for
>> >dedicating a section for ReplacementFor channels in the RSVP APC. Is
>> >that fine or am I missing something?
>>
>> If I understand the RSVP method correctly, I think you're right.
>>
>> As long as nothing special or different needs to be done while
>> using ReplacementFor vs. ordinary LC opening and closing, we
>> don't need to mention it specially.  I think this is the case.
>>
>> The only thing special (which I already mentioned in the RepFor
>> appendix text) is reminding impelementors to increase the RSVP
>> bandwidth _before_ switching to a higher rate channel, or to
>> reduce it _after_ switching to a lower rate channel.
>>
>> Do you agree?
>>
>> --Dave L.
>>
>> -------------------------------------------------------------------
>> Dave Lindbergh                       Email: lindbergh at pictel.com
>> Manager, Technical Standards Group   Voice: +1 508 623 4351
>> PictureTel Corporation               Fax:   +1 508 749 2804
>> 100 Minuteman Road - M/S 635         H.320: +1 508 437 0265 (twice)
>> Andover MA 01810  USA                http://standards.pictel.com
>> PGP fingerprint:  C8 3E 28 69 53 0A 4B 87  EF E0 11 CD AC 87 4D CD
>> -------------------------------------------------------------------
>
>--
>Hussein Salama
>Cisco Systems, IOS Development
>(408) 527-7147
>170 W. Tasman Dr., San Jose, CA 95134
>
-------------------------------------------------------------------
Dave Lindbergh                       Email: lindbergh at pictel.com
Manager, Technical Standards Group   Voice: +1 508 623 4351
PictureTel Corporation               Fax:   +1 508 749 2804
100 Minuteman Road - M/S 635         H.320: +1 508 437 0265 (twice)
Andover MA 01810  USA                http://standards.pictel.com
PGP fingerprint:  C8 3E 28 69 53 0A 4B 87  EF E0 11 CD AC 87 4D CD
-------------------------------------------------------------------



More information about the sg16-avd mailing list