Network Working GroupInternet Engineering Task Force (IETF) B. ChengInternet-DraftRequest for Comments: 8646 D. WigginsIntended status:Category: Standards Track MIT Lincoln LaboratoryExpires: December 15, 2019ISSN: 2070-1721 L. Berger, Ed. LabN Consulting, L.L.C.June 13,September 2019DLEP Control Plane BasedDynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extensiondraft-ietf-manet-dlep-pause-extension-08Abstract This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 15, 2019.https://www.rfc-editor.org/info/rfc8646. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Extension Usage and Identification . . . . . . . . . . . . . 3 3. Extension Data Items . . . . . . . . . . . . . . . . . . . . 3 3.1. Queue Parameters . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Queue ParameterSub DataSub-Data Item . . . . . . . . . . . . 5 3.2. Pause . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Restart . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. Extension Type Value . . . . . . . . . . . . . . . . . .910 5.2. Data Item Values . . . . . . . . . . . . . . . . . . . . 10 5.3. QueueParameters Sub DataParameter Sub-Data Item Values . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 11Appendix A.Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. It provides the exchange oflink relatedlink-related control information between a modem and a router. DLEP defines a base set of mechanisms as well as support for possible extensions. This document defines one such extension. The base DLEP specification does not include anydata plane flow controldata-plane flow-control capability. The extension defined in this document supports flow control of data traffic based on explicit messages sent via DLEP by a modem to indicate when a router should hold off sendingtraffic,traffic and when it should resume. This functionality parallels theflow controlflow-control mechanism found in PPP over Ethernet (PPPoE) per [RFC5578]. The extension also optionally supportsDSCP (differentiated services codepoint) awareDSCP-aware flow control ("DSCP" stands for "Differentiated Services Code Point") for use byDiffServ-awareDiffserv-aware modems. (For general background on DifferentiatedServicesServices, see [RFC2475].) This functionality is very similar to that provided by EthernetPrioritypriority-based flowcontrol,control; see [IEEE.802.1Q_2014]. The extension defined in this document is referred to as"Control Plane Based"Control-Plane-Based Pause". Otherflow controlflow-control methods are possible withDLEP, e.g.,DLEP; for example, see[I-D.ietf-manet-dlep-da-credit-extension][DLEP-DIFFSERV] and[I-D.ietf-manet-dlep-credit-flow-control].[DLEP-CREDIT]. Note that this mechanism only applies to traffic that is to be transmitted on the modem's attached data channel and not to DLEP control messages themselves.FurthermoreFurthermore, it applies only to the singlesub-networksubnetwork that is used to connect a modem and a router, and for traffic sent from a router to a modem. This document defines a new DLEP Extension Type Valuein Section 2 whichthat is used to indicate the use of theextension, and threeextension; see Section 2. Three new DLEP Data Items are defined in Section 3. 1.1. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Extension Usage and Identification The use of theControl Plane BasedControl-Plane-Based Pause Extension SHOULD be configurable. To indicate that the implementation supports the use of theControl Plane BasedControl-Plane-Based Pause Extension, an implementation MUST include theControl Plane BasedControl-Plane-Based Pause Extension Type Value in the Extensions Supported Data Item. The Extensions Supported Data Item is sent and processed according to [RFC8175]. TheControl Plane BasedControl-Plane-Based Pause Extension Type Value isTBA1,2; see Section 5. 3. Extension Data Items Threedata itemsData Items are defined by this extension. The Queue Parameters Data Item is used by a modem to provide information about the DSCPs it uses in forwarding. The Pause Data Item is used by a modem to indicate when a router should cease sendingpacketspackets, and the Restart Data Item is used by a modem to indicate when a router can resume sending packets. 3.1. Queue Parameters The Queue Parameters Data Item is sent by a modem totoa router to indicate DSCP values that may be independently paused. Thisdata itemData Item MUST be included in a Session Initialization Response Message that also contains theControl Plane BasedControl-Plane-Based Pause Extension Type Value in the Extensions Supported Data Item. Updates to these parameters MAY be sent by a modem by including thedata itemData Item in Session Update Messages. The Queue Parameters Data Item groups DSCPs into logical queues, each of which is identified by a "QueueIndex".Index" field. The number of logicalqueues, or queue indexes,queues isvariablevariable, as is the number of DSCPs associated with each queue. A queue size (in bytes) is provided for informational purposes. QueueIndexesIndex fields are numbered sequentially from zero, where queue index zero is a special case covering DSCPswhichthat are not otherwise associated with a QueueIndex.Index field. An implementation that does not support DSCPs would indicate1one queue with0zero DSCPs, and the number of bytes that may be in its associated link transmit queue. Additional logical queues are represented in a variable series of Queue Parametersub data items.Sub-Data Items. The format of the Queue Parameters Data Item is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Queues | Scale | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue ParameterSub DataSub-Data Item 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue ParameterSub DataSub-Data Item n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type:TBA223 Length: Variable Per[RFC8175][RFC8175], Length is the number of octets in thedata item,Data Item, excluding the Type and Length fields. Num Queues: An 8-bit unsigned integer indicating the number of queues represented in thedata item.Data Item. This field MUST contain a value of at least one(1),(1) and is equal to one greater than the number of included Queue ParameterSub DataSub-Data Items. Scale: A 4-bit unsigned integer indicating the scale used in the Queue Sizefields.Qn field. The valid values are: Value Scale-------------------------------------------- 0 B - Bytes (Octets) 1KiBKB - Kilobytes (1024 B) 2MiBMB - Megabytes (1024KiB)KB) 3GiBGB - Gigabytes (1024MiB)MB) Reserved: A 20-bit field that MUST be set to zero (0) by the sender (a modem) and ignored by the receiver (a router). 3.1.1. Queue ParameterSub DataSub-Data Item Queue ParameterSub DataSub-Data Items are an unordered list composed ofsub data itemsSub-Data Items with a common format. The format of the Queue ParameterSub DataSub-Data Item is patterned after the standard format for the DLEPdata item format,Data Item; see[RFC8175][RFC8175], Section 11.3. Any errors or inconsistencies encountered in parsingSub DataSub-Data Items are handled in the same fashion as any other Data Item parsing error encountered in DLEP. In particular, the receiving implementation MUST issue a Session Termination Message containing a Status Data Item with status code set to 130'Invalid Data'("Invalid Data") and transition to the Session Termination state. The format of the Queue ParameterSub DataSub-Data Item is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub DataSub-Data Item Type (1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and Value has the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Index | Queue Size Qn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num DSCPs Qn | DS Field Qn | ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... | DS Field Qn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sub DataSub-Data Item Type: A 16-bit unsigned integer that indicates the type and corresponding format of theSub DataSub-Data Item's Value field.Sub DataSub-Data Item Types are scoped within the Data Item in which they are carried, i.e., theSub DataSub-Data Item Type field MUST be used together with the Queue Parameters Data Item Type to identify the format of theSub DataSub-Data Item. This field MUST be set to one (1) for the Queue ParameterSub DataSub-Data Item. Length: Variable Length is the number of octets in thesub data item,Sub-Data Item, excluding the Type and Length fields. Queue Index: An 8-bit field indicating the queue index of the queue parameter represented in thesub data item.Sub-Data Item. Only the first instance of a particular Queue Index value is meaningful. Subsequentsub data itemsSub-Data Items containing the same Queue Index values, if present, MAY be logged via a management interface and MUST otherwise be ignored. Note that the value 255 is reserved and MUST NOT be used in this field. Queue Size Qn: A 24-bit unsigned integer representing the size, in the octet scale indicated by the Scale field, of the queuesupportingthat supports the traffic with the DSCPs associated with the queue index. Num DSCPs Qn: An 8-bit unsigned integer indicating the number of DSCPs associated with the queue index associated with thesub data item.Sub-Data Item. This field MUST contain a value of at least one (1). DS Field Qn: Thedata itemData Item contains a sequence of8 bit8-bit DSFields.fields. The number of DSFieldsfields present MUST equal thevalue of theNum DSCPsfield.Qn field value. The DSFieldfield structure is the same as the structure shown in [RFC2474]. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DSCP | CU | +---+---+---+---+---+---+---+---+ DSCP:differentiated services codepointDifferentiated Services Code Point CU:currently unused,Currently Unused; MUST be zero 3.2. Pause The Pause Data Item is sent by a modem to a router to indicate to its peer that traffic is to be suppressed, i.e., paused. The motivating use case for thisdata itemData Item is when a modem's internal queue length exceeds a particular threshold. Other use cases are possible, e.g., when there arenon queue relatednon-queue-related congestion points within a modem. Such cases are not explicitly described in this document. A modem can indicate that traffic is to be suppressed on adevice- widedevice-wide or destination-specific basis. An example of when a modem might usedevice wide indicationsdevice-wide suppression is when output queues are shared across alldestinations, and destination specificdestinations. Destination-specific suppression might be used whenper destinationper-destination queuing is used. To indicate that suppression applies to all destinations, a modem MUST send the Pause Data Item in a Session Update Message. To indicate that suppression applies to a particulardestinationdestination, a modem MUST send the Pause Data Item in a Destination Update Message. Each Pause Data Item identifies the traffic to be suppressed by the Queue Indexdefined by Section 3.1,field (Section 3.1), which in turn indicatesa set oftraffic identified by one or more DSCPs. The special value of 255 is used to indicate that all traffic is to be suppressed. While there is no restriction on the number ofMessagesmessages containing Pause DataItemItems that may be sent by a modem, a modem SHOULD include multiple queue indexes in the same message when possible. A routerwhichthat receives the Pause Data Item MUST cease sending the identified traffic to the modem. This may of course translate into the router's queues exceeding their own thresholds. If a received Pause Data Item contains a Queue Index value other than 255 or a queue index established by a Session Initialization or Session Update Message, the router MUST terminate the session with a Status Data Item indicatingInvalid Data."Invalid Data". The format of the Pause Data Item is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Index | ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... | Queue Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type:TBA324 Length: Variable Per[RFC8175][RFC8175], Length is the number of octets in thedata item,Data Item, excluding the Type and Length fields. It will equal the number of Queue Index fields carried in thedata item.Data Item. Queue Index: One or more 8-bit fields used to indicate a queue index defined by a Queue Parameters Data Item. The special value of 255 indicates that (1) all traffic to the modem is to be suppressedto the modem,when thedata itemData Item is carried in a Session UpdateMessage,Message or (2) all traffic to a particular destination is to be suppressedto a destination,when thedata itemData Item is carried in a Destination Update Message. 3.3. Restart The Restart Data Item is sent by a modem to a router to indicate to its peer that transmission of previously suppressed traffic may be resumed. An example of when a modem might send thisdata itemData Item is when an internal queue length drops below a particular threshold. The sending of thisdata itemData Item parallels the Pause DataItem, see the previous section,Item (see Section 3.2) and follows the same rules.As above, toTo indicate that transmission can resume to all destinations, a modem MUST send the Restart Data Item in a Session Update Message.It also includes that toTo indicate that transmission can resume to a particulardestinationdestination, a modem MUST send thePauseRestart Data Item in a Destination Update Message. Finally,queue indexes are interpreted inthe sameway as in the Pause Data Item..rules apply to queue indexes. A routerwhichthat receives the Restart Data Item SHOULD resume transmission of the identified traffic to the modem. The format of the Restart Data Item matches the Pause Data Item and is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Index | ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... | Queue Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type:TBA425 Length: See Section 3.2. Queue Index: See Section 3.2. 4. Security Considerations The extension defined in this document introduces a new mechanism for flow control between a router and modem using DLEP. The extension does not introduce any vulnerabilities that are inherently different from those documented in [RFC8175]. The approach taken toSecuritysecurity in that document applies equally when running the extension defined in this document. Implementations of the extension defined in this document MUST support the configuration and use ofTLS usage,TLS, asdescribedescribed in [RFC8175], in order to protect configurations where injection attacks are possible, i.e., when the link between a modem and router is not otherwise protected. Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router or a switch that interconnects the modem and router. Similar attacks are generally possible with baseDLEP,DLEP -- forexampleexample, an impersonating modem may cause a sessionresetreset, or a compromised modemsimplycan simply drop all traffic destinedto,for or sent by a router. [RFC8175] defines the use of TLS to protect againstthesuch impersonatingattacker.attackers. 5. IANA Considerations This documentrequests the assignment of 4assigns four new valuesby IANA. All assignments are to registries defined by [RFC8175].and creates a new subregistry in the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry. 5.1. Extension Type Value This documentrequests 1adds a new assignment to the DLEPExtensions Registryextensions registry named "Extension Type Values"in the range with[RFC8175], per the "Specification Required"policy. The requested value is as follows:policy [RFC8126]. IANA has assigned the following value: +------+---------------------------+ | Code | Description | +------+---------------------------+ |TBA12 |Control Plane BasedControl-Plane-Based Pause | +------+---------------------------+ Table 1:RequestedExtension Type Value 5.2. Data Item Values This documentrequests 3adds three new assignments to the DLEP Data ItemRegistryregistry named "Data Item Type Values"in the range with[RFC8175], per the "Specification Required"policy. The requested values are as follows:policy [RFC8126]. IANA has assigned the following values: +-----------+------------------+ | Type Code | Description | +-----------+------------------+ |TBA223 | Queue Parameters | | | | |TBA324 | Pause | | | | |TBA425 | Restart | +-----------+------------------+ Table 2:RequestedData Item Values 5.3. QueueParameters Sub DataParameter Sub-Data Item ValuesUpon approval of this document,IANAis requested to createhas created a new DLEPregistry,registry named "QueueParameters Sub DataParameter Sub-Data Item Type Values".The following tableTable 3 provides initial registry values and the[RFC8126] definedregistration policies [RFC8126] thatshould apply to the registry:apply: +-------------+------------------------+ | Type Code | Description/Policy | +-------------+------------------------+ | 0 | Reserved | | | | | 1 | Queue Parameter | | | | | 2-65407 | Specification Required | | | | | 65408-65534 | Private Use | | | | | 65535 | Reserved | +-------------+------------------------+ Table33: Initial Registry Values 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, DOI 10.17487/RFC8175, June 2017, <https://www.rfc-editor.org/info/rfc8175>. 6.2. Informative References[I-D.ietf-manet-dlep-credit-flow-control][DLEP-CREDIT] Cheng, B., Wiggins, D., Berger, L., and S. Ratliff, "DLEP Credit-Based Flow Control Messages and Data Items",draft- ietf-manet-dlep-credit-flow-control-04 (workWork inprogress),Progress, draft-ietf-manet-dlep-credit-flow-control-04, March 2019.[I-D.ietf-manet-dlep-da-credit-extension][DLEP-DIFFSERV] Cheng, B., Wiggins, D., and L. Berger, "DLEP DiffServ Aware Credit Window Extension",draft-ietf-manet-dlep-da- credit-extension-07 (workWork inprogress),Progress, draft- ietf-manet-dlep-da-credit-extension-07, March 2019. [IEEE.802.1Q_2014] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,DOI 10.1109/ieeestd.2014.6991462, December 2014, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6991460>.<https://ieeexplore.ieee.org/document/6991462>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>. [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, February 2010, <https://www.rfc-editor.org/info/rfc5578>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.Appendix A.Acknowledgments Thesub data itemformat for the Sub-Data Item was inspired by Rick Taylor's "Data Item Containers" idea. Authors' Addresses Bow-Nan Cheng MIT Lincoln Laboratory Massachusetts Institute of Technology 244 Wood Street Lexington, MA 02421-6426 United States of America Email: bcheng@ll.mit.edu David Wiggins MIT Lincoln Laboratory Massachusetts Institute of Technology 244 Wood Street Lexington, MA 02420-9108 United States of America Email: David.Wiggins@ll.mit.edu Lou Berger (editor) LabN Consulting, L.L.C. Email: lberger@labn.net