| Based on the discussion, I plan to submit to the meeting this week the following text as the scope for the PAR modification:
This standard describes a management channel for devices
used in Ethernet-based subscriber access networks. The key characteristics of
the specified management channel are: -
The ability to transit MAC bridges in a single
IEEE 802 MAC domain to allow remote management of devices. -
Extensibility to accommodate new management
protocols and new types of devices. -
The ability to simultaneously send messages to multiple
UMT stations using broadcast or multicast addressing.
The standard describes the message format as well as
processing operations at the stations participating in the UMT protocol.
Additional comments are welcome, of course.
—kan—
I also agree with dropping “that would not normally be forwarded” I also think Kevin’s broadcast/multicast text better captures the essence of capabilities. The only changes I would make are the words simultaneous and addressing, as in “the ability to send messages to multiple stations simultaneously using broadcast or multicast addressing” Curtis I agree with dropping the text as suggested by Glen. It unnecessarily limits the protocol. I don’t like the broadcast/multicast bullet as it currently is written because the broadcast/multicast capability could be used for more than just synchronized configuration, and further, it’s up to the client protocol to put the broadcast/multicast capability to its own good use (potentially including simultaneous/synchronized configuration). For this reason, I propose replacing that bullet with “the ability to send messages to multiple stations using broadcast or multicast functions” However, this is not a point to which I am married. —kan—
I don’t think we should broaden the scope of this project to cover 802.11 or 802.16, even just as use cases. I also don’t like “IEEE 802 Suite” in place of “Ethernet-based subscriber access networks”, because IEEE 1904.1 SIEPON standard falls under “Ethernet-based subscriber access networks”, but it doesn’t fall under “IEEE 802 Suite”. Here is the scope I propose (changes marked vs. the current PAR) This standard describes a management channel for customer-premises equipment (CPE) connected to devices used in Ethernet-based subscriber access networks. The key characteristics of the specified management channel are: - Multi-hop capabilities to allow management of various CPE devices located behind an Optical Network Unit (ONU), a Coaxial Network Unit (CNU), a Residential Gateway (RGW), etc. The ability to transit MAC-bridges in a single IEEE 802 MAC domain to allow remote management of devices using protocols that would not normally be forwarded. - Extensibility to accommodate new management protocols and/or new types of CPE devices. - Broadcast/multicast capabilities to allow simultaneous (synchronized) configuration of multiple devices. - Encryption capabilities to ensure secure access to managed CPE devices by the network operators.
- The standard describes the message format as well as processing operations at the end-stations and forwarding rules at the intermediate nodes. I used Kevin’s 1st sub-bullet. But I am not sure about the text in blue. The UMT can carry IP packets, and that is not link-local protocol. Should we just drop “using protocols that would not normally be forwarded”? Or should we expand it to say “using protocols that would not normally be forwarded in layer 2 domain”? Any other suggestions? I do not recall the exact concern with “ethernet-based access networks”… I only have a note to clarify “ethernet-based”. I adjusted the language in a way that I thought would meet that requirement. I adopted the “IEEE 802 Suite” term to do this. This is not an unprecedented way to reference all the 802 protocols… in fact, 802.1 does almost the same thing… "An architecture for the interconnection of IEEE 802® Local Area Networks (LANs) below the MAC Service boundary is defined" Re: expansion of the scope to include .16 and .11 etc… There is no need for us to explicitly define operation over these networks. To Marek’s point, they use Ethernet framing or can natively transport Ethernet frames and bridging in those networks is well defined in the respective standards, so it should “just work”. If there is a need for any additional references in 1904.2, it would be to 802.1, but I don’t think that is required in the PAR scope. As requested by the group during the last meeting, I posted a proposal for the changes in the PAR scope. My proposal reflects all the concerns expressed during the call. The comments received so far reflect concerns in the proposal, but there are, so far, no proposed changes to the proposed text. Perhaps suggestions to change the proposed text, or alternative proposals will help converge the discussion. All,
Can someone remind me what was the specific objection to the term
"Ethernet-based subscriber access networks" on the last call? Like Marek, I
also don't see anything ambiguous or confusing about this. But I do have a
concern about expanding the scope to cover 802.11 and 802.16 standards. That
was never discussed in the TF2 before. Not do I think this will fly with
the Nescom. On the one hand, we took too long even with the existing scope
and are asking NesCom for additional time, on the other hand, we are trying
to significantly expand the scope of the project. There are no .11 or .16
representatives or affiliates in TF2 and I don't think NesCom will be keen
to approve this change.
I do remember we decided to include the CO-based devices, in addition to the
currently-listed CPE devices. Also, we talked for a long time about removing
the encryption. I don't see what other changes are needed.
Thank you,
-Glen
-----Original Message-----
From: Kevin A Noll [mailto:ieee.lists@xxxxxxxxxxxxxxx]
Sent: Wednesday, August 08, 2018 12:35 PM
To: STDS-1904-WG@xxxxxxxxxxxxxxxxx
Subject: Re: [1904-ANWG] PAR Modification for IEEE 1904.2
I cannot find a reference in IEEE 802 or any of its parts that refer to all
the parts as “Ethernet”. Can you provide such reference?
Either way, whatever we call it, it just needs to be clear. This was a point
of discussion in the meeting, so I attempted to clarify it.
Regarding transiting MAC bridges: The original text was “multi-hop
capabilities” and there was discussion in the last meeting that this could
mean L2 or L3 and that it should be clarified. This is my attempt to do
that. Is there a better way to state this?
—kan—
On Aug 8, 2018, at 8:43 AM, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
wrote:
Kevin,
All .11, .16, etc. is still Ethernet so I do not really understand the
issue here - perhaps it is just something I missed in understanding what
was wrong with " Ethernet-based subscriber access networks" to begin with.
As far as transiting MAC bridges is concerned - do we need to say
anything, really, provided that we use proper MAC addressing, it is
inherent
Marek
-----Original Message-----
From: Kevin A Noll <ieee.lists@xxxxxxxxxxxxxxx>
Sent: Wednesday, August 8, 2018 8:34 AM
To: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Cc: stds-1904-wg@xxxxxxxxxxxxxxxxx; stds-1904-2-TF@xxxxxxxxxxxxxxxxx;
Fernando Villarruel <villarf@xxxxxxxxx>; Pradeep Kondamuri
<pkondamu@xxxxxxxxx>; Edward A Walter <ew8532@xxxxxxx>
Subject: Re: PAR Modification for IEEE 1904.2
1. I chose to use “IEEE 802 Suite” because this protocol should be able to
operate in the context of any of the protocols defined under IEEE 802… for
example, it should be able to operate over an 802.11 link, and an 802.16
link, etc etc. Arguably, those are PHY layers, but they are NOT Ethernet
(802.3), but we should cover those as use cases.
Can you suggest text that would be clearer, but still cover that scope?
2. “Ability to transit MAC-bridges” was meant to clarify the original
“multi-hop” statement. It seems to me that this should be stated for the
exact example that you give… one of the use cases is to enable a method
for protocols that would normally be link-local to transit a MAC bridge.
Do you have alternative text to suggest that would be more clear or
precise?
3. “Single 802 MAC domain”… I agree that this term is not well
established. Refer to (1) above … the intent is to communicate that
“multi-hop” could mean that the frames could cross multiple link types.
Suggested text?
—kan—
On Aug 3, 2018, at 7:30 AM, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
wrote:
Personally, I do not k now what was wrong with " Ethernet-based
subscriber access networks" to begin with. Perhaps someone can explain it
to me what is wrong with this term - the way I read it, it is anything
that runs Ethernet, irrespective of the media underneath; and if we run
Ethernet, we can run this new management protocol of ours. The " the IEEE
802 suite" term is not any clearer and I would argue - it is way more
vague and ill-defined.
The " ability to transit MAC-bridges" is inherent to any L2 frame unless
it is explicitly link local.
I also do not know " in a single IEEE 802 MAC domain" is a
well-established term and what it is intended to mean. For link-local
protocols, this would be just link itself. I believe what you mean in
here is L2 broadcast domain, i.e., as far as any broadcast L2 frame
would reach. This is the term I saw used before
Marek
-----Original Message-----
From: stds-1904-wg@xxxxxxxx <stds-1904-wg@xxxxxxxx> On Behalf Of Kevin
A Noll
Sent: Thursday, August 2, 2018 7:39 PM
To: stds-1904-wg@xxxxxxxxxxxxxxxxx; stds-1904-2-TF@xxxxxxxxxxxxxxxxx
Cc: Fernando Villarruel <villarf@xxxxxxxxx>; Pradeep Kondamuri
<pkondamu@xxxxxxxxx>; Edward A Walter <ew8532@xxxxxxx>
Subject: PAR Modification for IEEE 1904.2
Colleagues,
During the 1 August 2018 meeting we discussed the need to modify the
scope of the PAR for IEEE 1904.2.
There was consensus that
1. encryption should be removed from the scope, 2. "Ethernet-based”
should be clarified, 3. the type of devices to be managed needs to be
expanded beyond “CPE”
4. “Multi-hop” should be clarified to limit the scope to Layer-2
The current PAR Scope reads as follows:
This standard describes a management channel for customer-premises
equipment (CPE) connected to Ethernet-based subscriber access networks.
The key characteristics of the specified management channel are:
- Multi-hop capabilities to allow management of various CPE devices
located behind an Optical Network Unit (ONU), a Coaxial Network Unit
(CNU), a Residential Gateway (RGW), etc.
- Extensibility to accommodate new management protocols and/or new types
of CPE devices.
- Broadcast/multicast capabilities to allow simultaneous (synchronized)
configuration of multiple devices.
- Encryption capabilities to ensure secure access to managed CPE devices
by the network operators.
The standard describes the message format as well as processing
operations and forwarding rules at the intermediate nodes.
I propose the following as an updated scope:
This standard describes a management channel for devices used in
subscriber access networks that use protocols in the IEEE 802 suite. The
key characteristics of the management channel are:
- The ability to transit MAC-bridges in a single IEEE 802 MAC domain to
allow management of devices using protocols that would not normally be
forwarded.
- Extensibility to accommodate new management protocols and new types of
devices.
- The ability to simultaneously send messages to multiple stations using
broadcast or multicast functions.
This standard describes the message format as well as processing
operations of stations and MAC-bridges.
Please reply with comments and suggested edits.
—kan—
Kevin A. Noll
______________________________________________________________________
__ To unsubscribe from the STDS-1904-WG list, click the following
link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-WG&A=1
______________________________________________________________________
__ To unsubscribe from the STDS-1904-2-TF list, click the following
link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1
To unsubscribe from the STDS-1904-WG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-WG&A=1
To unsubscribe from the STDS-1904-WG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-WG&A=1
|