draft-ietf-opsawg-capwap-hybridmac-02.txt | draft-ietf-opsawg-capwap-hybridmac-03.txt | |||
---|---|---|---|---|
Network Working Group C. Shao | Network Working Group C. Shao | |||
Internet-Draft H. Deng | Internet-Draft H. Deng | |||
Intended status: Standards Track China Mobile | Intended status: Standards Track China Mobile | |||
Expires: August 18, 2014 R. Pazhyannur | Expires: November 6, 2014 R. Pazhyannur | |||
Cisco | Cisco Systems | |||
F. Bari | F. Bari | |||
AT&T | AT&T | |||
R. Zhang | R. Zhang | |||
China Telecom | China Telecom | |||
S. Matsushima | S. Matsushima | |||
SoftBank Telecom | SoftBank Telecom | |||
February 14, 2014 | May 5, 2014 | |||
IEEE 802.11 MAC Profile for CAPWAP | IEEE 802.11 MAC Profile for CAPWAP | |||
draft-ietf-opsawg-capwap-hybridmac-02 | draft-ietf-opsawg-capwap-hybridmac-03 | |||
Abstract | Abstract | |||
CAPWAP defines two entities Wireless Transmission Point (WTP) and | CAPWAP defines two entities: Wireless Transmission Point (WTP) and | |||
Access Controller (AC). CAPWAP also defines two MAC (Medium Access | Access Controller (AC). CAPWAP also defines two MAC (Medium Access | |||
Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each | Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each | |||
MAC mode, CAPWAP describes how the MAC functionality is split between | MAC mode, CAPWAP describes how the MAC functionality is split between | |||
the WTP and AC. However, certain functions have not been clearly | the WTP and AC. However, certain functions have not been clearly | |||
defined. For example for the Split MAC mode, the IEEE 802.11 | defined. For example in the Split MAC mode description, the IEEE | |||
encryption is specified as located in either the AC or the WTP with | 802.11 encryption is specified as located in either the AC or the WTP | |||
no clear way for the AC to inform the WTP where it should be. This | with no clear way for the AC to inform the WTP where it should be. | |||
lack of specification leads to interoperability especially when AC | This lack of specification leads to interoperability especially when | |||
and WTP come from different vendors. To solve the problem, this | AC and WTP come from different vendors. To solve the problem, this | |||
specification defines a IEEE 802.11 MAC profile where each profile | specification defines a IEEE 802.11 MAC profile where each profile | |||
specifies an unambigous division of functionality between the WTP and | specifies an unambiguous division of functionality between the WTP | |||
AC. The IEEE 802.11 MAC profile is used as follows: The WTP informs | and AC. The IEEE 802.11 MAC profile is used as follows: the WTP | |||
the AC of the supported profiles during the discovery or join process | informs the AC of the supported profiles during the discovery or join | |||
and the AC configures the WTP with one of the supported profiles | process and the AC configures the WTP with one of the supported | |||
while configuring a WLAN. | profiles while configuring the WLAN. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 18, 2014. | This Internet-Draft will expire on November 6, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 43 | skipping to change at page 3, line 43 | |||
| |Assoc/Disassoc/Reassoc | WTP/AC | AC | | | |Assoc/Disassoc/Reassoc | WTP/AC | AC | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Classifying | WTP | AC | | | |Classifying | WTP | AC | | |||
+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 802.11 QoS |Scheduling | WTP | WTP/AC | | | 802.11 QoS |Scheduling | WTP | WTP/AC | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Queuing | WTP | WTP | | | |Queuing | WTP | WTP | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |IEEE 802.1X/EWTP | AC | AC | | | |IEEE 802.1X/EWTP | AC | AC | | |||
+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 802.11 RSN |RSNA Key Management | WTP | AC | | | 802.11 RSN |RSNA Key Management | AC | AC | | |||
+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |IEEE 802.11 | WTP | WTP/AC | | | |IEEE 802.11 | WTP | WTP/AC | | |||
+ |Encryption/Decryption | | | | + |Encryption/Decryption | | | | |||
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: Functions in Local MAC and Split MAC | Figure 1: Functions in Local MAC and Split MAC | |||
To solve this problem, this specification introduces IEEE 802.11 MAC | To solve this problem, this specification introduces IEEE 802.11 MAC | |||
profle. The MAC profile unamabigously specifies where the various | profile. The MAC profile unambiguously specifies where the various | |||
MAC fucntionality should be located. | MAC functionality should be located. | |||
2. Conventions used in this document | 2. Conventions used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
3. IEEE MAC Profile Descriptions | 3. IEEE MAC Profile Descriptions | |||
A IEEE MAC Profile refers to a description of how the MAC | A IEEE MAC Profile refers to a description of how the MAC | |||
functionality is split between the WTP and AC shown in Figure 1 | functionality is split between the WTP and AC shown in Figure 1 | |||
3.1. Split MAC with WTP encryption | 3.1. Split MAC with WTP encryption | |||
The functional split for the Split MAC with WTP encryption is | The functional split for the Split MAC with WTP encryption is | |||
provided in Figure 2. This profile is similar to the Split MAC | provided in Figure 2. This profile is similar to the Split MAC | |||
except that IEEE 802.11 encryption/decryption is at the WTP. Note | description in [RFC5416] except that IEEE 802.11 encryption/ | |||
that fragmentation is always done at the same entity as the | decryption is at the WTP. Note that fragmentation is always done at | |||
encryption. Consequently, in this profile fragmentation/ | the same entity as the encryption. Consequently, in this profile | |||
defragmentation is also done only at the WTP Note that scheduling | fragmentation/defragmentation is also done only at the WTP Note that | |||
functionality is denoted as WTP/AC. As explained in [RFC5416], this | scheduling functionality is denoted as WTP/AC. As explained in | |||
means that the admission control component of IEEE 802.11 resides on | [RFC5416], this means that the admission control component of IEEE | |||
the AC, the real-time scheduling and queuing functions are on the | 802.11 resides on the AC, the real-time scheduling and queuing | |||
WTP. | functions are on the WTP. | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Functions | Profile | | | Functions | Profile | | |||
| | 0 | | | | 0 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Distribution Service | AC | | | |Distribution Service | AC | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Integration Service | AC | | | |Integration Service | AC | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Beacon Generation | WTP | | | |Beacon Generation | WTP | | |||
skipping to change at page 5, line 44 | skipping to change at page 5, line 44 | |||
+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |IEEE 802.11 | WTP | | | |IEEE 802.11 | WTP | | |||
+ |Encryption/Decryption | | | + |Encryption/Decryption | | | |||
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: Functions in Split MAC with WTP Encryption | Figure 2: Functions in Split MAC with WTP Encryption | |||
3.2. Split MAC with AC encryption | 3.2. Split MAC with AC encryption | |||
The functional split for the Split MAC with AC encryption is provided | The functional split for the Split MAC with AC encryption is provided | |||
in Figure 3. This profile is similar to the Split MAC except that | in Figure 3. This profile is similar to the Split MAC in [RFC5416] | |||
IEEE 802.11 encryption/decryption is done only at the AC. Since | except that IEEE 802.11 encryption/decryption is at the AC. Since | |||
fragmentation is always done at the same entity as the encryption, in | fragmentation is always done at the same entity as the encryption, in | |||
this rofile, AC does fragmentation/defragmentation. | this profile, AC does fragmentation/defragmentation. | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Functions | Profile | | | Functions | Profile | | |||
| | 1 | | | | 1 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Distribution Service | AC | | | |Distribution Service | AC | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Integration Service | AC | | | |Integration Service | AC | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Beacon Generation | WTP | | | |Beacon Generation | WTP | | |||
skipping to change at page 6, line 43 | skipping to change at page 6, line 43 | |||
| 802.11 RSN |RSNA Key Management | AC | | | 802.11 RSN |RSNA Key Management | AC | | |||
+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |IEEE 802.11 | AC | | | |IEEE 802.11 | AC | | |||
+ |Encryption/Decryption | | | + |Encryption/Decryption | | | |||
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 3: Functions in Split MAC with AC encryption | Figure 3: Functions in Split MAC with AC encryption | |||
3.3. IEEE 802.11 MAC Profile Frame Exchange | 3.3. IEEE 802.11 MAC Profile Frame Exchange | |||
An example of message exchange using the the IEEE 802.11 MAC Profile | An example of message exchange using the IEEE 802.11 MAC Profile | |||
message element is shown in Figure 4. The WTP informs the AC of the | message element is shown in Figure 4. The WTP informs the AC of the | |||
various MAC profiles it supports. This happens either in a Discovery | various MAC profiles it supports. This happens either in a Discovery | |||
Request message or the Join Request message. The AC determines the | Request message or the Join Request message. The AC determines the | |||
appropriate profile and the configures the WTP with the profile while | appropriate profile and the configures the WTP with the profile while | |||
configuring the WLAN. | configuring the WLAN. | |||
+-+-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |||
| WTP | | AC | | | WTP | | AC | | |||
+-+-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |||
|Join Request[Supported IEEE 802.11 | | |Join Request[Supported IEEE 802.11 | | |||
skipping to change at page 7, line 45 | skipping to change at page 7, line 45 | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 | 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 | |||
+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | +=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |||
| Num_Profiles | Profile_1 | Profile_[2..N].. | | Num_Profiles | Profile_1 | Profile_[2..N].. | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |||
Figure 5: IEEE 802.11 Supported MAC Profiles | Figure 5: IEEE 802.11 Supported MAC Profiles | |||
o Type: TBD for IEEE 802.11 Supported MAC Profiles | o Type: TBD for IEEE 802.11 Supported MAC Profiles | |||
o Num_Profiles >=1: This refers to number of profiles present in | o Num_Profiles >=1: This refers to number of profiles present in | |||
this messaage element. There must be at least one profile. | this message element. There must be at least one profile. | |||
o Profile: Each profile is idnentified by a value specified in | o Profile: Each profile is idnentified by a value specified in | |||
Section 4.2. | Section 4.2. | |||
4.2. IEEE 802.11 MAC Profile | 4.2. IEEE 802.11 MAC Profile | |||
The IEEE 802.11 MAC Profile message element allows the AC to select a | The IEEE 802.11 MAC Profile message element allows the AC to select a | |||
profile. This messsage element may be provided along with the IEEE | profile. This message element may be provided along with the IEEE | |||
802.11 ADD WLAN message element while configuring a WLAN on the WTP. | 802.11 ADD WLAN message element while configuring a WLAN on the WTP. | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+=+-+-+-+-+-+-+-+ | +=+-+-+-+-+-+-+-+ | |||
| Profile | | | Profile | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
Figure 6: IEEE 802.11 MAC Profile | Figure 6: IEEE 802.11 MAC Profile | |||
o Type: TBD for IEEE 802.11 MAC Profile | o Type: TBD for IEEE 802.11 MAC Profile | |||
skipping to change at page 8, line 35 | skipping to change at page 8, line 35 | |||
This document doesn't specify security risk difference from | This document doesn't specify security risk difference from | |||
[RFC5416]. Please refer to the Security section of [RFC5416] | [RFC5416]. Please refer to the Security section of [RFC5416] | |||
6. IANA Considerations | 6. IANA Considerations | |||
This document requires the following IANA actions. | This document requires the following IANA actions. | |||
o This specification defines a new message element, IEEE 802.11 | o This specification defines a new message element, IEEE 802.11 | |||
Supported MAC Profiles. The format of this option is described in | Supported MAC Profiles. The format of this option is described in | |||
Section 4.1. This value needs to be regsitered in the existing | Section 4.1. This value needs to be registered in the existing | |||
CAPWAP Message Element Type registry, defined in [RFC5415]. | CAPWAP Message Element Type registry, defined in [RFC5415]. | |||
o This specification defines a new message element, IEEE 802.11 MAC | o This specification defines a new message element, IEEE 802.11 MAC | |||
Profile. The format of this option is described in Section 4.2. | Profile. The format of this option is described in Section 4.2. | |||
This value needs to be regsitered in the existing CAPWAP Message | This value needs to be registered in the existing CAPWAP Message | |||
Element Type registry, defined in [RFC5415]. | Element Type registry, defined in [RFC5415]. | |||
o The Profile field in the IEEE 802.11 Supported MAC Profiles | o The Profile field in the IEEE 802.11 Supported MAC Profiles | |||
message element and IEEE 802.11 MAC Profile message element (see | message element and IEEE 802.11 MAC Profile message element (see | |||
Section 4.2) is used to denote the MAC profile. This document | Section 4.2) is used to denote the MAC profile. This document | |||
defines two values, zero (0) and one (1), and the remaining values | defines two values, zero (0) and one (1), and the remaining values | |||
(2-255) are controlled and maintained by IANA and require an | (2-255) are controlled and maintained by IANA and require an | |||
Expert Review. | Expert Review. | |||
7. Contributors | 7. Contributors | |||
skipping to change at page 9, line 25 | skipping to change at page 9, line 25 | |||
Guidance from management team: Melinda Shore, Scott Bradner, Chris | Guidance from management team: Melinda Shore, Scott Bradner, Chris | |||
Liljenstolpe, Benoit Claise, Joel Jaeggli, Dan Romascanu are highly | Liljenstolpe, Benoit Claise, Joel Jaeggli, Dan Romascanu are highly | |||
appreciated. | appreciated. | |||
9. Normative References | 9. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, | ||||
"Objectives for Control and Provisioning of Wireless | ||||
Access Points (CAPWAP)", RFC 4564, July 2006. | ||||
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And | [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And | |||
Provisioning of Wireless Access Points (CAPWAP) Protocol | Provisioning of Wireless Access Points (CAPWAP) Protocol | |||
Specification", RFC 5415, March 2009. | Specification", RFC 5415, March 2009. | |||
[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and | [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and | |||
Provisioning of Wireless Access Points (CAPWAP) Protocol | Provisioning of Wireless Access Points (CAPWAP) Protocol | |||
Binding for IEEE 802.11", RFC 5416, March 2009. | Binding for IEEE 802.11", RFC 5416, March 2009. | |||
Authors' Addresses | Authors' Addresses | |||
skipping to change at page 10, line 4 | skipping to change at page 9, line 42 | |||
Authors' Addresses | Authors' Addresses | |||
Chunju Shao | Chunju Shao | |||
China Mobile | China Mobile | |||
No.32 Xuanwumen West Street | No.32 Xuanwumen West Street | |||
Beijing 100053 | Beijing 100053 | |||
China | China | |||
Email: shaochunju@chinamobile.com | Email: shaochunju@chinamobile.com | |||
Hui Deng | Hui Deng | |||
China Mobile | China Mobile | |||
No.32 Xuanwumen West Street | No.32 Xuanwumen West Street | |||
Beijing 100053 | Beijing 100053 | |||
China | China | |||
Email: denghui@chinamobile.com | Email: denghui@chinamobile.com | |||
Rajesh S. Pazhyannur | Rajesh S. Pazhyannur | |||
Cisco | Cisco Systems | |||
170 West Tasman Drive | 170 West Tasman Drive | |||
San Jose, CA 95134 | San Jose, CA 95134 | |||
USA | USA | |||
Email: rpazhyan@cisco.com | Email: rpazhyan@cisco.com | |||
Farooq Bari | Farooq Bari | |||
AT&T | AT&T | |||
7277 164th Ave NE | 7277 164th Ave NE | |||
Redmond WA 98052 | Redmond WA 98052 | |||
End of changes. 21 change blocks. | ||||
41 lines changed or deleted | 37 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |