DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
General Remarks:
1/Claims 1-8, 17-18, and 21-30 are pending
2/ Claims 1, 5, 17 and 18 are independent
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-8, 17-18, and 21-30 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 5, 17, 18 recites the limitations:
-“…a Software Defined Networking, SDN, controller…”.
t is not clear if SDN Acronyms that are a Software Defined Networking is an independent attribute by itself. The way the coma used around the Acronym is confusing. When acronym is introduced the first time, the Acronym is put in parenthesis without comma.
- “…a first maximum segment identifier ‘SID’ Depth, MSD, type…”. It is not clear if SID and MSD are Acronyms that are part of the maximum segment identifier depth or are an independent attributes by themselves. The way the coma used around the Acronym is confusing. When acronym is introduced the first time, the Acronym is put in parenthesis without comma or single quotation. Examiner suggests writing the above as “…a first maximum segment identifier (SID) Depth (MSD) type…
Regarding claims 2, 6, 23, 28, recites:
- “…Multi-Protocol Label Switching, MPLS,…:.
-“… Segment Routing over Internet Protocol version 6'IPv6', SRv6, Imposition MSD”.
The way the coma used around the Acronym is confusing. When acronym is introduced the first time, the Acronym is put in parenthesis without comma.
Regarding claim 3, 7, 21, 24, 26, 29, recites:
-“…Interior Gateway Protocol, IGP, …”.
-“…Intermediate System to Intermediate System, IS-IS, or Open Shortest Path First, OSPF, protocol”.
The way the coma used around the Acronym is confusing. When acronym is introduced the first time, the Acronym is put in parenthesis without comma.
Regarding claim 4, 22, 25, 27, 30 recites “…Border Gateway Protocol - Link State, BGP-LS, or Path Computation Element Protocol, PCEP”. The way the coma used around the Acronym is confusing. When acronym is introduced the first time, the Acronym is put in parenthesis without comma.
Regarding claim 8, recites “…a Software Defined Networking, SDN, controller using Border Gateway Protocol - Link State, BGP-LS, or Path Computation Element Protocol, PCEP”. The way the coma used around the Acronym is confusing. When acronym is introduced the first time, the Acronym is put in parenthesis without comma.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-8, 17-18, and 21-30 is/are rejected under 35 U.S.C. 103 as being unpatentable over RFC8491 “Signaling Maximum SID Depth (MSD) Using IS-IS”, further in view of Tansura (WO2017141081A1).
Regarding claim 1.RFC 8491 discloses a method in a first communication device, comprising:
advertising, to a second communication device or a centralized controller, a first Maximum Segment Identifier 'SID' Depth, MSD, type, a first MSD value associated with the first MSD type, a second MSD type, and a second MSD value associated with the second MSD type (page 2, Signaling MSD using IS-IS, discloses In order for BGP-LS to signal MSD for all the nodes (second communication device) and links in the network for which MSD is relevant, MSD capabilities SHOULD be advertised by every Intermediate System to Intermediate System (IS-IS) router in the network; Abstract discloses This document defines a way for an Intermediate System to i1ntermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers that corresponds to controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network; fig. 1 discloses plurality of MSD types with corresponding MSD types advertised using sub-TLV), the first MSD value indicating a maximum number of SIDs that is supported by the first communication device (page 2 MSD signaling MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 represents the lack of ability to support a SID stack of any depth; any other value represents that of the node. This value MUST represent the lowest value supported (maximum number of SIDs) by any link configured for use by the advertising IS-IS instance; fig. 1 discloses plurality of MSD types with corresponding MSD types advertised using sub-TLV), and the second MSD value indicating a maximum number of SIDs that can be imposed at the first communication device with one pass through a packet processing pipeline (page 2 MSD signaling MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 represents the lack of ability to support a SID stack of any depth; any other value represents that of the node. This value MUST represent the lowest value supported (maximum number of SIDs) by any link configured for use by the advertising IS-IS instance; fig. 1 discloses plurality of MSD types with corresponding MSD types advertised using sub-TLV).
But, RFC 8491 does not explicitly disclose: advertising, to a Software Defined Networking, SDN, controller, a Maximum Segment Identifier 'SID' Depth, MSD, type;
However, in the same field of endeavor, Tansura discloses advertising, to a Software Defined Networking, SDN, controller, a Maximum Segment Identifier 'SID' Depth, MSD, type ([0048] Thus, when Segment Routing tunnels are computed by a centralized controller (e.g., a Path Computation Element (PCE) or SDN controller), it is crucial that the controller knows what the “Maximum SID Depth” (or “MSD”) of the particular node is, so that it does not attempt to create a path/tunnel with a set of SID that is deeper (i.e., larger) than what the node is capable of inserting into the traffic; [0017-0018] In some embodiments, the TLV element is advertised utilizing the IS-IS protocol. In some embodiments, the TLV element is an IS-IS Router Capability TLV. [0018] In some embodiments, the MSD value is carried within a node MSD sub-TLV carried by the IS-IS Router Capability TLV; [0055-0056] this system includes a controller 104 (SDN controller) and six network elements A-F (102A-102F) serving as the forwarding plane of the SR network 120 …network element ‘A’ 102A determines an MSD value 112 (e.g., two), and advertises the MSD value 112 within a TLV element 110. In some embodiments, this TLV element 110 is sent as part of an IGP advertisement, such as within an OSPF LSA or IS-IS TLV…as the network element ‘A’ 102A likely is not in direct communication with the controller, and instead, the advertised TLV 110 may be sent out one or more (or all) of its interfaces leading to other IGP-participating nodes, and eventually the advertised TLV 110 can be provided to the controller 104 at circle ‘2’).
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of RFC 8491. The modification would allow centralized control of path computation with global knowledge of MSD of nodes. The modification would allow effective path computation and selection for effectively forward data
Regarding claim 2. The combination discloses method of claim 1.
RFC 8491 discloses wherein the first MSD type is Base Multi-Protocol Label Switching, MPLS, or Segment Routing over Internet Protocol version 6'IPv6', SRv6, Imposition MSD (page 2 discloses This document defines an extension to IS-IS used to advertise one or more types of MSDs at node and/or link granularity. It also creates an IANA registry for assigning MSD-Type identifiers and defines the Base MPLS Imposition MSD-Type. In the future, it is expected that new MSD-Types will be defined to signal additional capabilities, e.g., entropy labels, SIDs that can be imposed through recirculation, or SIDs associated with another data plane such as IPv6).
Regarding claim 3. The combination discloses the method of claim 1,
Tansura discloses wherein the second communication device is in a same Interior Gateway Protocol, IGP, domain as the first communication device ([0123] advertisement module can advertise the MSD value of the "node" and/or "links," which can be determined based upon the capabilities of the NIC(s) 944, and can be advertised using an IGP such as OSPF or IS-IS (indicating of nodes of the same IGP domain)), and the first MSD type, the first MSD value, the second MSD type, and the second MSD value are advertised to the second communication device using an Intermediate System to Intermediate System, IS-IS, or Open Shortest Path First, OSPF, protocol( [0056] network element ‘A’ 102A determines an MSD value 112 (e.g., two), and advertises the MSD value 112 within a TLV element 110. In some embodiments, this TLV element 110 is sent as part of an IGP advertisement, such as within an OSPF LSA or IS-IS TLV. As is known those of skill in the art, this advertisement can travel a variety of physical communication paths, as the network element ‘A’ 102A likely is not in direct communication with the controller, and instead, the advertised TLV 110 may be sent out one or more (or all) of its interfaces leading to other IGP-participating nodes, and eventually the advertised TLV 110 can be provided to the controller 104. The system is capable of advertising multiple types of MSD values).
Regarding claim 4. The combination discloses method of claim 1.
RFC 8491 discloses, wherein the first MSD type, the first MSD value, the second MSD type, and the second MSD value are advertised to the centralized controller using Border Gateway Protocol - Link State, BGP-LS, or Path Computation Element Protocol, PCEP (page 2 discloses of Link-State and TE Information Using Border Gateway Protocol)[RFC7752] defines a way to expose topology and associated attributes and capabilities of the nodes in that topology to a centralized controller… MSD signaling by BGP-LS has been defined in [MSD-BGP].Typically, BGP-LS is configured on a small number of nodes that do not necessarily act as head-ends. In order for BGP-LS to signal MSD for all the nodes and links in the network for which MSD is relevant, MSD capabilities SHOULD be advertised by every Intermediate System to Intermediate System (IS-IS) router in the network).
Tansura discloses MSD value are advertised to SDN controller ([0048] Thus, when Segment Routing tunnels are computed by a centralized controller (e.g., a Path Computation Element (PCE) or SDN controller), it is crucial that the controller knows what the “Maximum SID Depth” (or “MSD”) of the particular node is, so that it does not attempt to create a path/tunnel with a set of SID that is deeper (i.e., larger) than what the node is capable of inserting into the traffic; [0017-0018] In some embodiments, the TLV element is advertised utilizing the IS-IS protocol. In some embodiments, the TLV element is an IS-IS Router Capability TLV. [0018] In some embodiments, the MSD value is carried within a node MSD sub-TLV carried by the IS-IS Router Capability TLV; [0055-0056] this system includes a controller 104 (SDN controller) and six network elements A-F (102A-102F) serving as the forwarding plane of the SR network 120 …network element ‘A’ 102A determines an MSD value 112 (e.g., two), and advertises the MSD value 112 within a TLV element 110. In some embodiments, this TLV element 110 is sent as part of an IGP advertisement, such as within an OSPF LSA or IS-IS TLV…as the network element ‘A’ 102A likely is not in direct communication with the controller, and instead, the advertised TLV 110 may be sent out one or more (or all) of its interfaces leading to other IGP-participating nodes, and eventually the advertised TLV 110 can be provided to the controller 104 at circle ‘2’).
Regarding claim 5. RFC8491 discloses a method in a second communication device or a centralized controller, the method comprising:
receiving, from a first communication device a first Maximum Segment Identifier 'SID' Depth, MSD, type, a first MSD value associated with the first MSD type a second MSD type, and a second MSD value associated with the second MSD type ( (page 2, Signaling MSD using IS-IS, discloses In order for BGP-LS to signal MSD for all the nodes (second communication device) and links in the network for which MSD is relevant, MSD capabilities SHOULD be advertised by every Intermediate System to Intermediate System (IS-IS) router (first device when sending advertisement and second device when receiving advertisement) in the network; fig. 1 discloses plurality of MSD types with corresponding MSD types advertised using sub-TLV; Abstract discloses This document defines a way for an Intermediate System to i1ntermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers that corresponds to controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network), the first MSD value indicating a maximum number of SIDs that is supported by the first communication device (page 2 MSD signaling MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 represents the lack of ability to support a SID stack of any depth; any other value represents that of the node. This value MUST represent the lowest value supported (maximum number of SIDs) by any link configured for use by the advertising IS-IS instance; fig. 1 discloses plurality of MSD types with corresponding MSD types advertised using sub-TLV), and the second MSD value indicating a maximum number of SIDs that can be imposed at the first communication device with one pass through a packet processing pipeline (page 2 MSD signaling MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 represents the lack of ability to support a SID stack of any depth; any other value represents that of the node. This value MUST represent the lowest value supported (maximum number of SIDs) by any link configured for use by the advertising IS-IS instance; fig. 1 discloses plurality of MSD types with corresponding MSD types advertised using sub-TLV).
But, RFC 8491 does not explicitly disclose:
a method in a Software Defined Networking, SDN, controller, the method comprising: receiving, from a first communication device a Maximum Segment Identifier 'SID' Depth, MSD, type, a MSD value;
However, in the same field of endeavor, Tansura discloses a method in a Software Defined Networking, SDN, controller, the method comprising: receiving, from a first communication device a Maximum Segment Identifier 'SID' Depth, MSD, type, a MSD value ([0048] Thus, when Segment Routing tunnels are computed by a centralized controller (e.g., a Path Computation Element (PCE) or SDN controller), it is crucial that the controller knows what the “Maximum SID Depth” (or “MSD”) of the particular node is, so that it does not attempt to create a path/tunnel with a set of SID that is deeper (i.e., larger) than what the node is capable of inserting into the traffic; [0017-0018] In some embodiments, the TLV element is advertised utilizing the IS-IS protocol. In some embodiments, the TLV element is an IS-IS Router Capability TLV. [0018] In some embodiments, the MSD value is carried within a node MSD sub-TLV carried by the IS-IS Router Capability TLV; [0055-0056] this system includes a controller 104 (SDN controller) and six network elements A-F (102A-102F) serving as the forwarding plane of the SR network 120 …network element ‘A’ 102A determines an MSD value 112 (e.g., two), and advertises the MSD value 112 within a TLV element 110. In some embodiments, this TLV element 110 is sent as part of an IGP advertisement, such as within an OSPF LSA or IS-IS TLV…as the network element ‘A’ 102A likely is not in direct communication with the controller, and instead, the advertised TLV 110 may be sent out one or more (or all) of its interfaces leading to other IGP-participating nodes, and eventually the advertised TLV 110 can be provided to the controller 104 at circle ‘2’).
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of RFC 8491. The modification would allow centralized control of path computation with global knowledge of MSD of nodes. The modification would allow effective path computation and selection for effectively forward data
Regarding claim 6. The combination discloses method of claim 5.
All other limitations of claim 6 are similar with limitations of claim 2 rejected above.
Regarding claim 7. The combination discloses method of claim 5.
All other limitations of claim 7 are similar with the limitations of claim 3 rejected above.
Regarding claim 8. The combination discloses method of claim 5.
All other limitations of claim 8 are similar with the limitations of claim 4 rejected above.
Regarding claim 17. RFC8491 discloses a first communication device, comprising a communication interface, a processor and a memory to configure the first communication device to (page 2, Signaling MSD using IS-IS, discloses In order for BGP-LS to signal MSD for all the nodes (second communication device when receiving advertisement and first communication device when sending one) and links in the network for which MSD is relevant, MSD capabilities SHOULD be advertised by every Intermediate System to Intermediate System (IS-IS) router in the network where the nodes comprise memory):
All other limitations of claim 17 are similar with the limitations of claim 1 rejected above.
Regarding claim 18. RFC8491 discloses a second communication device or a Software Defined, SDN, controller, comprising a communication interface, a processor and a memory, the memory comprising instructions executable by the processor whereby the second communication device or the SDN controller is configured to (page 2, Signaling MSD using IS-IS, discloses In order for BGP-LS to signal MSD for all the nodes (second communication device when receiving advertisement and first communication device when sending one) and links in the network for which MSD is relevant, MSD capabilities SHOULD be advertised by every Intermediate System to Intermediate System (IS-IS) router in the network where the nodes comprise memory):
All other limitations of claim 18 are similar with the limitations of claim 5 rejected above.
Regarding claim 21. The combination discloses method of claim 2.
All other limitations of claim 21 are similar with the limitations of claim 3 rejected above.
Regarding claim 22. The combination discloses method of claim 2.
All other limitations of claim 22 are similar with the limitations of claim 4 rejected above.
Regarding claim 23. The combination discloses first communication device of claim 17.
All other limitations of claim 23 are similar with the limitations of claim 2 rejected above.
Regarding claim 24. The combination discloses first communication device of claim 17.
All other limitations of claim 24 are similar with the limitations of claim 3 rejected above.
Regarding claim 25. The Combination discloses the first communication device of claim 17.
All other limitations of claim 25 are similar with the limitations of claim 4 rejected above.
Regarding claim 26. The combination discloses method of claim 6.
All other limitations of claim 26 are similar with the limitations of claim 3 rejected above.
Regarding claim 27. The combination discloses method of claim 6.
All other limitations of claim 27 are similar with the limitations of claim 4 rejected above.
Regarding claim 28. The combination discloses second communication device or SDN controller of claim 18.
All other limitations of claim 28 are similar with the limitations of claim 2 rejected above.
Regarding claim 29. The combination discloses second communication device or SDN controller of claim 18.
All other limitations of claim 29 are similar with the limitations of claim 3 rejected above.
Regarding claim 30. The combination discloses second communication device or SDN controller of claim 18.
All other limitations of claim 30 are similar with the limitations of claim 4 rejected above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MESSERET F. GEBRE whose telephone number is (571)272-8272. The examiner can normally be reached 9:00 am-5:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar Louie can be reached at 5712701684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MESSERET F GEBRE/Primary Examiner, Art Unit 2445