PPP config-request basic Question - PPP

This is a discussion on PPP config-request basic Question - PPP ; Hi all, When you send a config-request from Peer A to B, for example with a option say protocol field compression (PFC) does it mean, A will send packets compressed with PFC or A is willing to receive packets compressed ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: PPP config-request basic Question

  1. PPP config-request basic Question

    Hi all,

    When you send a config-request from Peer A to B, for example with a
    option say protocol field compression (PFC) does it mean, A will send
    packets compressed with PFC or A is willing to receive packets
    compressed with PFC? If somebody can clarify will really appreciate
    it.

    Thanks,
    Fr0do.

  2. Re: PPP config-request basic Question

    In comp.protocols.ppp fr0do wrote:
    > Hi all,


    > When you send a config-request from Peer A to B, for example with a
    > option say protocol field compression (PFC) does it mean, A will send
    > packets compressed with PFC or A is willing to receive packets
    > compressed with PFC? If somebody can clarify will really appreciate
    > it.


    It means A is willing to receive PPP messages sent by B with PFC
    compressed protocol fields. B can Configure-Ack the request but
    is not required to use PFC.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* They that can give up essential liberty to obtain a little temporary
    safety deserve neither liberty nor safety." Benjamin Franklin */


  3. Re: PPP config-request basic Question

    Thanks Clifford, Does it mean that a PPP stack on a machine usually
    maintains two sets state structures for options, for example lets say
    a send structure ( which holds Auth, ACFC, PFC values of the current
    link ) and a same recv structure. Because each side of the connection
    can negotiate different options as A can talk to B with ACFC and PFC
    but B doesnt do compression and can talk to A without compression.

    Fr0do.

    Clifford Kite wrote in message news:...
    > In comp.protocols.ppp fr0do wrote:
    > > Hi all,

    >
    > > When you send a config-request from Peer A to B, for example with a
    > > option say protocol field compression (PFC) does it mean, A will send
    > > packets compressed with PFC or A is willing to receive packets
    > > compressed with PFC? If somebody can clarify will really appreciate
    > > it.

    >
    > It means A is willing to receive PPP messages sent by B with PFC
    > compressed protocol fields. B can Configure-Ack the request but
    > is not required to use PFC.


  4. Re: PPP config-request basic Question

    In comp.protocols.ppp fr0do wrote:
    > Thanks Clifford, Does it mean that a PPP stack on a machine usually
    > maintains two sets state structures for options, for example lets say
    > a send structure ( which holds Auth, ACFC, PFC values of the current
    > link ) and a same recv structure. Because each side of the connection
    > can negotiate different options as A can talk to B with ACFC and PFC
    > but B doesnt do compression and can talk to A without compression.


    The short answer is "I don't know." I know some things about PPP itself
    but am not a PPP implementor. That said, it does seem reasonable that
    each side would remember all the refinements negotiated in order to know
    when it can use a refinement and to avoid attempting to use refinements
    that weren't negotiated.

    Hopefully you'll get a more definitive and authoritative reply.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

  5. Re: PPP config-request basic Question

    In article <1f283ab4.0404162308.904a530@posting.google.com>,
    fr0do wrote:
    >Thanks Clifford, Does it mean that a PPP stack on a machine usually
    >maintains two sets state structures for options,


    Yes. A typical implementation will maintain 2 copies of the settings -
    one for the local side and one for the remote side.

    >for example lets say
    >a send structure ( which holds Auth, ACFC, PFC values of the current
    >link ) and a same recv structure. Because each side of the connection
    >can negotiate different options as A can talk to B with ACFC and PFC
    >but B doesnt do compression and can talk to A without compression.


    Exactly.

    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==================== What goes around, comes around... =====================

  6. Re: PPP config-request basic Question

    Thanks Patrick and Clifford.

    One last question, you said a config-request means, a request to
    receive, i tried to find this in RFC 1661 and couldnt see it anywhere,
    or did i miss something, 5.1 config-request section just talks about
    negotiating options never tells that it is explicitly for send or
    receive? Again is this gnerally accepted practice or did i miss it in
    the RFC.

    Thanks again.
    Fr0do.


    patrick@klos.com wrote in message news:...
    > In article <1f283ab4.0404162308.904a530@posting.google.com>,
    > fr0do wrote:
    > >Thanks Clifford, Does it mean that a PPP stack on a machine usually
    > >maintains two sets state structures for options,

    >
    > Yes. A typical implementation will maintain 2 copies of the settings -
    > one for the local side and one for the remote side.
    >
    > >for example lets say
    > >a send structure ( which holds Auth, ACFC, PFC values of the current
    > >link ) and a same recv structure. Because each side of the connection
    > >can negotiate different options as A can talk to B with ACFC and PFC
    > >but B doesnt do compression and can talk to A without compression.

    >
    > Exactly.
    >
    > ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    > Patrick Klos Email: patrick@klos.com
    > Klos Technologies, Inc. Web: http://www.klos.com/
    > ==================== What goes around, comes around... =====================


  7. Re: PPP config-request basic Question

    fr0do wrote:
    > patrick@klos.com wrote in message news:...
    >> In article <1f283ab4.0404162308.904a530@posting.google.com>,
    >> fr0do wrote:
    >>> Thanks Clifford, Does it mean that a PPP stack on a machine usually
    >>> maintains two sets state structures for options,

    >>
    >> Yes. A typical implementation will maintain 2 copies of the
    >> settings -
    >> one for the local side and one for the remote side.
    >>

    I presume that, in many cases the receiving end will not need to remember
    what's been negotiated however... For instance, in the case of the option
    you quote, PFC, the receiver probably doesn't need to remember anything...
    A protocol field value that is non-compressed and valid will be understood
    and a protocol field value that is compressed and valid will be understood
    too. So I guess the 'receiver' won't remember the negotiation status of
    PFC. I think...


    > One last question, you said a config-request means, a request to
    > receive, i tried to find this in RFC 1661 and couldnt see it anywhere,
    > or did i miss something, 5.1 config-request section just talks about
    > negotiating options never tells that it is explicitly for send or
    > receive? Again is this gnerally accepted practice or did i miss it in
    > the RFC.
    >

    I asked a similar question here and I quote from James Carlson's answer:
    Actually, except for clear design errors (such as RFC 1877), *all*
    options in PPP are negotiated in this way:
    Configure-Request means "please send me data with this set of
    options enabled."
    Configure-Ack means "I will now send you data with this set of
    options enabled."


    He also pointed out:
    RFC 1661 section 6 (page 39):
    Unless otherwise specified, all Configuration Options apply in a
    half-duplex fashion; typically, in the receive direction of the link
    from the point of view of the Configure-Request sender.
    Which I think is the section that you are looking for.

    Also from RFC 1661 about that specific option.
    6.5. Protocol-Field-Compression (PFC)
    ... This Configuration
    Option is sent to inform the peer that the implementation can
    receive such single octet Protocol fields.
    --
    Alan J. McFarlane
    http://homepage.ntlworld.com/alanjmcf/
    Please follow-up in the newsgroup for the benefit of all.



  8. Re: PPP config-request basic Question

    Thanks Alan! That defly helps. Appreciate it.

    -F

    "Alan J. McFarlane" wrote in message news:...
    > fr0do wrote:
    > > patrick@klos.com wrote in message news:...
    > >> In article <1f283ab4.0404162308.904a530@posting.google.com>,
    > >> fr0do wrote:
    > >>> Thanks Clifford, Does it mean that a PPP stack on a machine usually
    > >>> maintains two sets state structures for options,
    > >>
    > >> Yes. A typical implementation will maintain 2 copies of the
    > >> settings -
    > >> one for the local side and one for the remote side.
    > >>

    > I presume that, in many cases the receiving end will not need to remember
    > what's been negotiated however... For instance, in the case of the option
    > you quote, PFC, the receiver probably doesn't need to remember anything...
    > A protocol field value that is non-compressed and valid will be understood
    > and a protocol field value that is compressed and valid will be understood
    > too. So I guess the 'receiver' won't remember the negotiation status of
    > PFC. I think...
    >
    >
    > > One last question, you said a config-request means, a request to
    > > receive, i tried to find this in RFC 1661 and couldnt see it anywhere,
    > > or did i miss something, 5.1 config-request section just talks about
    > > negotiating options never tells that it is explicitly for send or
    > > receive? Again is this gnerally accepted practice or did i miss it in
    > > the RFC.
    > >

    > I asked a similar question here and I quote from James Carlson's answer:
    > Actually, except for clear design errors (such as RFC 1877), *all*
    > options in PPP are negotiated in this way:
    > Configure-Request means "please send me data with this set of
    > options enabled."
    > Configure-Ack means "I will now send you data with this set of
    > options enabled."
    >
    >
    > He also pointed out:
    > RFC 1661 section 6 (page 39):
    > Unless otherwise specified, all Configuration Options apply in a
    > half-duplex fashion; typically, in the receive direction of the link
    > from the point of view of the Configure-Request sender.
    > Which I think is the section that you are looking for.
    >
    > Also from RFC 1661 about that specific option.
    > 6.5. Protocol-Field-Compression (PFC)
    > ... This Configuration
    > Option is sent to inform the peer that the implementation can
    > receive such single octet Protocol fields.


+ Reply to Thread