Re: [pcp] Resolving contentious issue #3

   Dear all,

   In some cases the PCP Server should be instructed it must honour
   a request received from the PCP Client.  Examples of such cases is
   DSCP re-marking policies or returning the external perceived IP
   Address/port to detect the presence of the NAT.

   For illustration purposes, let focus on the DSCP marking case, the
   PCP Client should have means to assess whether

   1.  The PCP Server is able to enforce DSCP (re-)marking policies; in
       other words the PCP Server must support DSCP IE.

   2.  Its requested DSCP markings policies (direction: IN, OUT or both)
       has been successfully enforced by the PCP Server.  If the PCP Server
       fails to satisfy the DSCP marking policy as requested by the PCP
       Client, an error should be returned back to the PCP Client.

   A solution is to define a dedicated IE to instruct the PCP Server it
   MUST honour the request received from a PCP Client. The format of this
   IE is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   IE Code     | Reserved      |             0x00              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Mandatory IE

   1.  This IE can be included as the only IE in a request.  In such
       case, it is like the M-bit.

   2.  It can be included together with other IEs such as DSCP IE: The
       PCP Server must support those IEs and must satisfy the request,
       otherwise an error should be returned.

   The UPnP IGD-PCP IWF can be designed without a M-bit (see for
   instance http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-00#section-5.7.2.1) or with a
   M-bit as described in http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-00#section-5.7.2.2.  There are
   tradeoffs between the two alternatives.  Having the Mandatory-IE
   described above allows to design an UPnP IGD-PCP IWF in both modes.

   Cheers,

   Med

PS: The idea of the Mandatory-IE came in a discussion I had with Alain.

-----Message d'origine-----
De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Alain Durand
Envoyé : mercredi 3 novembre 2010 00:29
À : pcp@ietf.org
Cc : Dave Thaler
Objet : [pcp] Resolving contentious issue #3

The issue is: do we need a mandatory bit in the packet format?

It has been argued that a mandatory bit would simplify the UPnP/PCP inter-networking function.
So, the first question to resolve is:

3a: Is there a need for a mandatory bit for the pure PCP case? (ie outside the UPnP relay case)?
I have not heard any argument in that direction so far, so if there is a need there, now is the time to articulate it.

The second question to resolve is:
3b: for the UPnP intern-etworking function, a mandatory bit would simplify the server side implementation
because there will be less state to keep. Does this outweigh the added complexity in the protocol?
It has been argued that UPnP apps would go away and be replaced by PCP apps, so we can envision
a not too far future where the UPnP relay is not needed, so if the answer to 3a) is no, then PCP would
be better off long term by not having a mandatory bit.

I would like to open a 48 hour discussion window until Nov 4th, 5pm pacific time.

   - Alain.
_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************