Skip to main content

Diameter Support for Proxy Mobile IPv6 Localized Routing
draft-ietf-dime-pmip6-lr-18

Revision differences

Document history

Date Rev. By Action
2014-03-31
18 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-02-10
18 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-02-05
18 (System) RFC Editor state changed to RFC-EDITOR from REF
2014-02-03
18 (System) RFC Editor state changed to REF from EDIT
2013-12-23
18 (System) RFC Editor state changed to EDIT from MISSREF
2012-08-22
18 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2012-08-16
18 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-08-16
18 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2012-08-15
18 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-08-15
18 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-08-14
18 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2012-08-10
18 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-08-10
18 (System) IANA Action state changed to In Progress
2012-08-10
18 Amy Vezza State changed to Approved-announcement to be sent from None
2012-08-10
18 Amy Vezza IESG has approved the document
2012-08-10
18 Amy Vezza Closed "Approve" ballot
2012-08-10
18 Amy Vezza Ballot writeup was changed
2012-08-10
18 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::External Party
2012-08-10
18 Benoît Claise Ballot approval text was generated
2012-08-01
18 Qin Wu New version available: draft-ietf-dime-pmip6-lr-18.txt
2012-07-31
17 Qin Wu New version available: draft-ietf-dime-pmip6-lr-17.txt
2012-07-31
16 Qin Wu New version available: draft-ietf-dime-pmip6-lr-16.txt
2012-07-30
15 Benoît Claise
Before I put the document forward two things need to be clear:
1) Marco still co-authors or not? There has not been clear answer since …
Before I put the document forward two things need to be clear:
1) Marco still co-authors or not? There has not been clear answer since Marco indicated he might not be willing to co-author anymore
2) All authors are now "happy" with the content i.e. when the IETF LC goes out there won't be reopening A22 etc from the authors point of view.

Note: I've been letting the authors sort out those issues among themselves for 2 weeks now, but now, I just changed the draft state
2012-07-30
15 Benoît Claise State changed to IESG Evaluation::External Party from IESG Evaluation::AD Followup
2012-07-16
15 Benoît Claise Ballot writeup was changed
2012-07-16
15 Ralph Droms
[Ballot comment]
Thanks for addressing my remaining Discuss and Comment positions.  I've cleared my Discuss.

One remaining non-blocking comment:

In the abstract, I suggest s/In …
[Ballot comment]
Thanks for addressing my remaining Discuss and Comment positions.  I've cleared my Discuss.

One remaining non-blocking comment:

In the abstract, I suggest s/In Diameter Proxy Mobile IPv6/In a Proxy Mobile IPv6 deployment/
2012-07-16
15 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss
2012-07-16
15 Qin Wu New version available: draft-ietf-dime-pmip6-lr-15.txt
2012-07-13
14 Ralph Droms
[Ballot discuss]
1. Thanks for considering my Discuss position and revising the
document to show Diameter message flows for cases A11, A12 and A21
from …
[Ballot discuss]
1. Thanks for considering my Discuss position and revising the
document to show Diameter message flows for cases A11, A12 and A21
from RFC 6279.

2. It appears to me that all of the relevant addressing information is
available to the PMIPv6 participants in the mechanisms defined in
sections 5 of draft-ietf-netext-pmip-lr.  Therefore, the only required
AAA function is authorization of the localized routing request and the
references to "LMA" in "AAA(MFV, LMA)" in Figures 2, 3 and 4 can be
omitted.

3. The Introduction needs to be updated to conform with the message
flows in section 5.  In particular, these sentences are not
applicable:

  In these scenarios the information needed to set up a
  localized routing path (e.g., the addresses of the Mobile Access
  Gateways to which the MN and CN are respectively attached) is
  distributed between their respective Local Mobility Anchors.  This
  may complicate the setup and maintenance of localized routing.

  Therefore, in order to establish a localized routing path between the
  two Mobile Access Gateways, the Mobile Node's MAG must obtain the
  address of the Correspondent Node's MAG from the LMA that is managing
  the Correspondent Node's traffic.
2012-07-13
14 Ralph Droms
[Ballot comment]
These comments are all non-blocking editorial suggestions.

1. I think the last two sentences of the Abstract could be reworded
for clarity to …
[Ballot comment]
These comments are all non-blocking editorial suggestions.

1. I think the last two sentences of the Abstract could be reworded
for clarity to convey that this document describes how to use Diameter
to authorize the establishment of localized routing; perhaps:

  It may be desirable to control the establishment of localized
  routing sessions between two MAGs by requiring that the session be
  authorized.  This document specifies how to implement this
  authorization using the Diameter protocol.

2. In section 3, for clarity you might mention the case from RFC 6279
described in each of the first three bullet items.

3. In the title of section 4, s/Definitions/Used in this Document/  ?

4. In section 4.4, expand "HAAA" on first reference.

5. Also in section 4.4, for completeness, explanations of the meaning
of the INTER_MAG_ROUTING_SUPPORTED set to zero in both cases (one
MN-Identifier and two MN-Identifiers) should be included.
2012-07-13
14 Ralph Droms Ballot comment and discuss text updated for Ralph Droms
2012-07-13
14 Qin Wu New version available: draft-ietf-dime-pmip6-lr-14.txt
2012-05-15
13 Qin Wu New version available: draft-ietf-dime-pmip6-lr-13.txt
2012-05-11
12 Qin Wu New version available: draft-ietf-dime-pmip6-lr-12.txt
2012-05-08
11 Benoît Claise Ballot writeup was changed
2012-05-07
11 Ralph Droms
[Ballot discuss]
Updated on May 7 after e-mail discussion of my previous Discuss position.

This Discuss position asks about the relationship between this
document and …
[Ballot discuss]
Updated on May 7 after e-mail discussion of my previous Discuss position.

This Discuss position asks about the relationship between this
document and draft-ietf-netext-pmip-lr.  No action on the part of the
authors is required at this time.

1. From the introduction:

  This document describes Diameter [I-D.ietf-dime-rfc3588bis] support
  for the authorization and discovery of PMIPv6 mobility entities
  during localized routing.

If draft-ietf-netext-pmip-lr is the standards track document defining
PMIPv6 localized routing, why doesn't draft-ietf-dime-pmip6-lr simply
refer to draft-ietf-netext-pmip-lr and show where the Diameter
mechanisms it defines fit into the protocol operations defined in
sections 4, 5 and 6 of draft-ietf-netext-pmip-lr?

2. It appears to me that all of the relevant addressing information is
available to the PMIPv6 participants in the mechanisms defined in
sections 4, 5 and 6 of draft-ietf-netext-pmip-lr.  Therefore, assuming
draft-ietf-dime-pmip6-lr is not defining any new localized routing
signaling flows, the only required AAA function is authorization of
the localized routing request and section 4.1 can be omitted.
2012-05-07
11 Ralph Droms Ballot discuss text updated for Ralph Droms
2012-05-07
11 Ralph Droms
[Ballot discuss]
Updated on May 7 after e-mail discussion of my previous Discuss position.

This DISCUSS position asks about the relationship between this
document and …
[Ballot discuss]
Updated on May 7 after e-mail discussion of my previous Discuss position.

This DISCUSS position asks about the relationship between this
document and draft-ietf-netext-pmip-lr.  No action on the part of the
authors is required at this time.

1. From the introduction:

  This document describes Diameter [I-D.ietf-dime-rfc3588bis] support
  for the authorization and discovery of PMIPv6 mobility entities
  during localized routing.

If draft-ietf-netext-pmip-lr is the standards track document defining
PMIPv6 localized routing, why doesn't draft-ietf-dime-pmip6-lr simply
refer to draft-ietf-netext-pmip-lr and show where the Diameter
mechanisms it defines fit into the protocol operations defined in
sections 4, 5 and 6 of draft-ietf-netext-pmip-lr?

2. It appears to me that all of the relevant addressing information is
available to the PMIPv6 participants in the mechanisms defined in
sections 4, 5 and 6 of draft-ietf-netext-pmip-lr.  Therefore, assuming
draft-ietf-dime-pmip6-lr is not defining any new localized routing
signaling flows, the only required AAA function is authorization of
the localized routing request and section 4.1 can be omitted.
2012-05-07
11 Ralph Droms
[Ballot comment]
1. Figures 2 and 3 have a number of confusing typos.

2. (Moot if Figure 3 is modified or omitted.)  I don't see …
[Ballot comment]
1. Figures 2 and 3 have a number of confusing typos.

2. (Moot if Figure 3 is modified or omitted.)  I don't see anything in
draft-ietf-netext-pmip-lr that allows an LRA to carry the address of
an LMA.
2012-05-07
11 Ralph Droms Ballot comment and discuss text updated for Ralph Droms
2012-04-26
11 Glen Zorn New version available: draft-ietf-dime-pmip6-lr-11.txt
2012-04-25
10 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss
2012-03-29
10 Benoît Claise Responsible AD changed to Benoit Claise from Dan Romascanu
2012-03-29
10 Benoît Claise [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise
2012-03-07
10 Dan Romascanu Ballot writeup was changed
2012-03-02
10 Elwyn Davies Request for Telechat review by GENART Completed. Reviewer: Elwyn Davies.
2012-02-22
10 Dan Romascanu Ballot writeup text changed
2012-02-21
10 (System) New version available: draft-ietf-dime-pmip6-lr-10.txt
2012-02-17
10 Russ Housley
[Ballot discuss]
The authors have agreed to make some changes based on the Gen-ART
  Review by Elwyn Davies on 2-Feb-2012.  The changes have not …
[Ballot discuss]
The authors have agreed to make some changes based on the Gen-ART
  Review by Elwyn Davies on 2-Feb-2012.  The changes have not been
  posted yet.
2012-02-17
10 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2012-02-16
10 Cindy Morgan Removed from agenda for telechat
2012-02-16
10 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2012-02-16
10 Ralph Droms
[Ballot discuss]
I hope this Discuss issue will be easy to resolve.

To what extent has this document been reviewed by the netext WG?  I …
[Ballot discuss]
I hope this Discuss issue will be easy to resolve.

To what extent has this document been reviewed by the netext WG?  I
don't see any indication of review other than in the dime WG.  Given
that this document describes how PMIP6 uses Diameter mechanisms, I
would have expected at least a WG last call in netext, and I'm curious
about why the draft isn't a product of netext with review by dime.
2012-02-16
10 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded
2012-02-16
10 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2012-02-16
10 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2012-02-15
10 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2012-02-15
10 Peter Saint-Andre
[Ballot comment]
The term "Fully Qualified Domain Name" is undefined (specifically, it's unclear whether internationalized domain names are supported), but it appears that's the fault …
[Ballot comment]
The term "Fully Qualified Domain Name" is undefined (specifically, it's unclear whether internationalized domain names are supported), but it appears that's the fault of RFC 5779 and RFC 5447.
2012-02-15
10 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2012-02-15
10 Sean Turner [Ballot comment]
Curious to hear the response to Stephen's question.
2012-02-15
10 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2012-02-15
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2012-02-14
10 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2012-02-14
10 Robert Sparks
[Ballot discuss]
The relationship between this and the document specifying "Localized Routing for Proxy Mobile IPv6"
(currently in last call) is not clear. What level …
[Ballot discuss]
The relationship between this and the document specifying "Localized Routing for Proxy Mobile IPv6"
(currently in last call) is not clear. What level of coordination exists between DIME and NETEXT on these documents? Are the authorization steps described in this document actually part of the protocol being specified by netext?

Note that neither document currently references the other.
2012-02-14
10 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded
2012-02-14
10 Stephen Farrell
[Ballot comment]
A question and two comments, that could become discusses,
depending on the answer to the question. At present, I'm not
sure if there …
[Ballot comment]
A question and two comments, that could become discusses,
depending on the answer to the question. At present, I'm not
sure if there is a real issue here or not.

There could be a use-case where the MN's MAG is under the MN's
control. If there were, or if a MAG were compromised, or a
bad-actor, then this protocol could be used to track any
participating CN (whose address is known) at the level of the MAG
to which it is anchored, but I'm not sure how much of a concern
that ought be.  Note: I think (but am not sure) that this is different
from a "normally" bad MAG in most of pmipv6, in that it could
impact on a whole bunch of CN's and not just on the MN anchored
to the bad-MAG.

So, the question: How fine-grained a location would me knowing your
current MAG give me and is such potential tracking by a bad-MAG a
concern?

1. If this is a concern maybe it'd be useful to add something like
the following to the security considerations:

"An authorised MAG could in principle track the movement of any
participating CN at the level of the MAG to which they are anchored.
If such a MAG were compromised, or under the control of a bad-actor,
then such tracking could represent a privacy breach for the set of
tracked CN's. In such a case the traffic pattern from the
compromised MAG might be notable so monitoring for e.g. excessive
queries from MAGs might be worth while."

2. Assuming again that the answer to my question is that it is a
concern, ought there be some way in which e.g. MN2 in figure 6 could
be part of the authorisation process for this kind of feature?
Perhaps one could note that deployments that wanted to be privacy
friendly could provide some way to allow for a user to consent to
this? And going further of course any such consent might change
over time I guess.
2012-02-14
10 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded
2012-02-14
10 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2012-02-13
10 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2012-02-13
10 Russ Housley
[Ballot discuss]
The authors have agreed to make some changes based on the Gen-ART
  Review by Elwyn Davies on 2-Feb-2012.  The changes have not …
[Ballot discuss]
The authors have agreed to make some changes based on the Gen-ART
  Review by Elwyn Davies on 2-Feb-2012.  The changes have not been
  posted yet.
2012-02-13
10 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2012-02-13
09 (System) New version available: draft-ietf-dime-pmip6-lr-09.txt
2012-02-12
08 (System) New version available: draft-ietf-dime-pmip6-lr-08.txt
2012-02-09
10 Jean Mahoney Request for Telechat review by GENART is assigned to Elwyn Davies
2012-02-09
10 Jean Mahoney Request for Telechat review by GENART is assigned to Elwyn Davies
2012-02-09
10 Elwyn Davies Request for Last Call review by GENART Completed. Reviewer: Elwyn Davies.
2012-01-29
10 Dan Romascanu State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup.
2012-01-29
10 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu
2012-01-29
10 Dan Romascanu Ballot has been issued
2012-01-29
10 Dan Romascanu Created "Approve" ballot
2012-01-29
10 Dan Romascanu Placed on agenda for telechat - 2012-02-16
2012-01-26
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2012-01-26
07 (System) New version available: draft-ietf-dime-pmip6-lr-07.txt
2012-01-26
10 Dan Romascanu State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.
2012-01-24
10 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2012-01-17
10 Amanda Baber
IANA understands that, upon approval of this document, there is a single
action which IANA must complete.

In the Mobility Capability subregistry of the Authentication, …
IANA understands that, upon approval of this document, there is a single
action which IANA must complete.

In the Mobility Capability subregistry of the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at

http://www.iana.org/assignments/aaa-parameters

a new value will be added as follows:

Value: [ tbd ]
Token: INTER_MAG_ROUTING_SUPPORTED
Reference: [ RFC-to-be ]

IANA understands this to be the only action required to be completed
upon approval of this document.
2012-01-13
10 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2012-01-13
10 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2012-01-12
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Warren Kumari
2012-01-12
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Warren Kumari
2012-01-10
10 Amy Vezza Last call sent
2012-01-10
10 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Diameter Support for Proxy Mobile IPv6 Localized Routing) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Support for Proxy Mobile IPv6 Localized Routing'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the
  Mobile Access Gateway (MAG) to which it is attached are typically
  tunneled to a Local Mobility Anchor (LMA) for routing.  The term
  "localized routing" refers to a method by which packets are routed
  directly between an MN's MAG and the MAG of its Correspondent Node
  (CN) without involving any LMA.  In order to establish a localized
  routing session between two Mobile Access Gateways in a Proxy Mobile
  IPv6 domain, two tasks must be accomplished:




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr/


No IPR declarations have been submitted directly on this I-D.


2012-01-10
10 Dan Romascanu Last Call was requested
2012-01-10
10 Dan Romascanu State changed to Last Call Requested from AD Evaluation.
2012-01-10
10 Dan Romascanu Last Call text changed
2012-01-10
10 (System) Ballot writeup text was added
2012-01-10
10 (System) Last call text was added
2012-01-09
10 Dan Romascanu State changed to AD Evaluation from Publication Requested.
2011-12-13
10 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
--

Lionel Morand (lionel.morand@orange.com)
is the Document Shepherd, Dime co-chair. He has done a review
on the document and believes it is ready to be forwarded to
IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
--

The document has been discussed in the DIME WG for more than two
years, with different reviews of the updated version of the draft.
The lastest version is the result of the consensus reached
after discussion. However, only one review was done during the
WGLC.

The shepherd has reviewed the document himself and has no
issue with it. Nor the shepherd has issues with the reviews
done by others.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
--

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
--

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?
--

There is Dime WG consensus behind the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)
--

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?
--

The shepherd has checked the document with the idnits tool and
found no critical issues..

The document does not need MIB doctor review.
The document does not contain any media and URI types.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
--

References are split accordingly. There is no normative reference
to documents with unclear status or are in progress.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?
--

This document only defines new value in the Mobility Capability
registry (created by the RFC 5447) for use with the
MIP6-Feature-Vector AVP and requests IANA for value
assignment in the existing registry.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?
--

N/A

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
--

This document describes AAA support for the authorization and
discovery of Proxy Mobile IPv6 mobility entities (i.e. Local Mobility
Anchors and Mobile Access Gateways) during localized routing.
For this purpose, the document defines a new value for the
MIP6-Feature-Vector AVP originally defined in the RFC 5447 to
indicate
that Direct routing of IP packets between MNs anchored to the
different
MAG without involving any LMA is supported.

Working Group Summary
---

The document was discussed for more than two years in the WG
and
the document captures the results of the collaborative WG work.

Document Quality
---

The document is complete, straightforward, simple and
well-written.
2011-12-13
10 Cindy Morgan Draft added in state Publication Requested
2011-12-13
10 Cindy Morgan [Note]: 'Lionel Morand (lionel.morand@orange.com) is the document shepherd.' added
2011-12-13
10 Lionel Morand Proto Write-up provided by the document shepherd
2011-12-13
10 Lionel Morand IETF state changed to Submitted to IESG for Publication from In WG Last Call
2011-12-13
10 Lionel Morand Changed protocol writeup
2011-09-16
10 Jouni Korhonen Another 1 week WGLC due non-editorial changes from -05 to -06.

WGLC started 16-Sep-2011
WGLC ends 23-Sep-2011 23:59 CET+1
2011-09-16
10 Jouni Korhonen IETF state changed to In WG Last Call from In WG Last Call
2011-09-15
06 (System) New version available: draft-ietf-dime-pmip6-lr-06.txt
2011-06-29
05 (System) New version available: draft-ietf-dime-pmip6-lr-05.txt
2011-05-29
10 Jouni Korhonen
<-<-<-+                      |
                  |        …
<-<-<-+                      |
                  |                              |
                  |->->->-+  UO-0, UO-1*          |
                  |      +->->->->->->->-+      |
                  |                      +->->->-|  D_TRANS = D

  The compressor must not send packet types 1 or 0 when C_TRANS is P,
  i.e., not until it has received an ACK for a UOR-2, IR-DYN, or IR
  packet sent with the mode transition parameter set to C.  When the
  decompressor receives a UOR-2, IR-DYN, or IR packet sent with the
  mode transition parameter set to C, it must keep the value D_MODE as
  O and set D_TRANS to P.  When the decompressor receives packet types
  0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets
  D_TRANS to D.

Jonsson & Pelletier        Standards Track                    [Page 12]
RFC 3843                A ROHC Profile for IP                June 2004

A.2.  Transition from Unidirectional to Reliable Mode

  The cancellation of a transition from Unidirectional to Reliable mode
  follows the same procedure as defined in section 4.2 above.

A.3.  Transition from Reliable to Optimistic Mode

  When the decompressor initiates a mode transition from Reliable to
  Optimistic mode, the cancellation of the transition procedure is
  described as follows:

              Compressor                    Decompressor
            ----------------------------------------------
                  |                              |
                  |        ACK(O)/NACK(O) +-<-<-<-|  D_TRANS = I
                  |      +-<-<-<-<-<-<-<-+      |
  C_TRANS = P    |-<-<-<-+                      |
  C_MODE = R      |                              |
                  |->->->-+ IR/IR-DYN/UOR-2(SN,C) |
                  |      +->->->->->->->-+      |
                  |->-..                  +->->->-|  D_MODE = R
                  |->-..                          |
                  |          ACK(SN,R)  +-<-<-<-|
                  |      +-<-<-<-<-<-<-<-+      |
  C_TRANS = D    |-<-<-<-+                      |
                  |                              |
                  |->->->-+  R-0, R-1*          |
                  |      +->->->->->->->-+      |
                  |                      +->->->-|  D_TRANS = D
                  |                              |

  The compressor must not send packet types 1 or 0 when C_TRANS is P,
  i.e.,  not until it has received an ACK for a UOR-2, IR-DYN, or IR
  packet sent with the mode transition parameter set to C.  When the
  decompressor receives a UOR-2, IR-DYN, or IR packet sent with the
  mode transition parameter set to C, it must keep the value D_MODE as
  R.  When the decompressor receives packet types 0 or 1, after having
  ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.

Jonsson & Pelletier        Standards Track                    [Page 13]
RFC 3843                A ROHC Profile for IP                June 2004

A.4.  Transition Back to Unidirectional Mode

  When the decompressor initiates a mode transition from Reliable or
  Optimistic mode back to Unidirectional mode, the cancellation of the
  transition procedure is as follows:

              Compressor                    Decompressor
            ----------------------------------------------
              |                              |
              |        ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
              |      +-<-<-<-<-<-<-<-+      |
  C_TRANS = P |-<-<-<-+                      |
  C_MODE = O/R|                              |
              |->->->-+ IR/IR-DYN/UOR-2(SN,C) |
              |      +->->->->->->->-+      |
              |->-..                  +->->->-|
              |->-..                          |
              |          ACK(SN,O/R)  +-<-<-<-|
              |      +-<-<-<-<-<-<-<-+      |
  C_TRANS = D |-<-<-<-+                      |
              |          R-0, R-1* or        |
              |->->->-+  UO-0, UO-1*          |
              |      +->->-&No comments or reviews received. The Document stays in WGLC for another two weeks.
2011-05-29
10 Jouni Korhonen Annotation tag Other - see Comment Log set.
2011-05-29
10 Jouni Korhonen started 12th May 2011
2011-05-29
10 Jouni Korhonen IETF state changed to In WG Last Call from WG Document
2011-05-05
04 (System) New version available: draft-ietf-dime-pmip6-lr-04.txt
2011-03-14
03 (System) New version available: draft-ietf-dime-pmip6-lr-03.txt
2010-11-23
02 (System) New version available: draft-ietf-dime-pmip6-lr-02.txt
2010-05-25
01 (System) New version available: draft-ietf-dime-pmip6-lr-01.txt
2010-02-21
00 (System) New version available: draft-ietf-dime-pmip6-lr-00.txt