How to Plan for Tactical Communications

As I just finished a year in a formal school, I find myself thinking back to my original Marine Corps schools and continually assessing how they have done and where they could have improved.  My instructors in Comm School did their very best to incorporate MCPP (Marine Corps Planning Process) into our formal learning.  Looking back, they did a pretty outstanding job given their student’s complete lack of familiarization with the process, but the sad reality is MCPP just doesn’t work for comm planning.  Knowing the process and how to be a meaningful contributor to the overall plan is important and should not be overlooked, but you are going to waste a lot of time and effort trying to make MCPP do anything meaningful for pure comm planning.

Probably the only thing more dangerous then trying to use MCPP for comm planning would be to use nothing.  Cisco has a pretty good process for network design – PPDIOO (Prepare, Plan, Design, Implement, Operate, Optimize).  PPDIOO is a great overall framework, but if you just look at it on the pages of a Cisco Press book (for instance “Official Cert Guide: CCDA 640-864”, which is an excellent book) you would probably think you would be better off going back to MCPP because the process has a lot to do with “cost of ownership”, “business agility”, and “business cases”.  Let me MC-ize this for you.

Prepare

Gather the requirements.  Some examples would be: uptime requirements, asset numbers (computers, phones, VTCs, radio nets, etc.).  Portions of this step are big blue arrows (very general guidance for any civilians reading this), but the importance of the detailed asset requirements should not be underestimated here.  DO NOT make the rookie mistake of shorting the CO or the SgtMaj.  Regardless of what they say, whatever assets you have available will be on their desk.  If they really don’t want them, you can always take the assets away, what will end up really causing you pain is if you give out all of the new wiz-bang IP phones and have to take one back once someone gets a taste.  A tactic that has always worked well for me is to double the number of columns on your spreadsheet and give the users a “want” and a “need” for every asset you detail.  This will keep the users from severely overshooting on the needs, and gives you an idea of where to put any excess assets after all of the needs have been covered.  The big blue arrow portion describes the overall theme or requirement.  Do your systems need to be “light” or have a high amount of uptime?  These concepts are mutually exclusive (even though the intent rarely is).  When we talk about “being ready to assume risk”, it is important to clarify whether you are meeting your Commander’s intent.  Regardless of how well you can configure the gear, if you only have one transmission system (WAN connection) and it goes down, that is it for you.  I’ve gone out single-threaded when the mission calls for it, but this is not the time to go strictly off of your perception of Commander’s intent.  Make sure you clarify with your Commander what you are planning to do.

Plan

Take the inputs from the prepare phase and put them to a physical location.  Here is an example: The S-4 section needs five computers, four of which will be in the S-4 tent, and the S-4 officer’s computer will be in the CoC. Tying assets to physical location will allow for proper capacity planning and will have a direct impact on your transmission, cabling, and power plans. This is a great time to take a step back and ask very simple questions to ensure you understand the user requirements. I normally end up asking a question like: “Do you need to talk from site A to site B, or do we also need to talk to site C. Additionally, do we need to be able to talk to them both simultaneously, or just have the ability to one at a time?” During this stage, physical assets should be tied to locations. You need to make sure these marry up. If you on have 50 computers in your CoC, a 48 port switch won’t cut it.  This is a great time to remind people how your life would be much easier if they keep the tents within 100m (Cat5 max distance) of each other.  It is your job to support, not to dictate terms.  Having said that, you only have so many transmission pieces, fiber cables and ports and if you put them all in the initial plan, you don’t have any flexibility for the future.

You’ve probably heard around 1,000,000 times not to plan in a vacuum, and this is no different.  Here is a recent example: I was present in all of the planning meetings, and actually listened when the engineers all spoke.  At one of the later planning meetings, some of the Ops guys wanted to move all the tents around to “better support the mission”, but the tolerances for all of the power cables were very tight and did not support this new setup.  The moral of the story is we each have our very specific requirements and they all need to marry up.  If we had gone off on our own and planned in a vacuum, the network design would have been immaculate, but it never would have been powered up (which tends to be important).

Design

The plan and design may seem similar, so an easy way to break it down is the plan covers (mostly) the physical world, and the design covers (mostly) the logical.  The design will cover how you work your external routing, internal routing, internal switching, IP address allocation, datacenter design, etc.  For the less technical planners, generally the lower you push routing (possibly down to the access layer) the better the performance, but the more tightly you will have to control IP addresses.  Alternatively, if you only route at the core, IP addressing will be very simple, but you can find yourself in a continuous battle with spanning-tree protocol and VLAN management.  This is one of the times where you need to have the intestinal fortitude to admit when you are in over your head.  Mis-steps here will have serious rammifications, if you have even a bit of a doubt, run your design by the nearest 0650.  I feel very confident in my abilities, but I have never given a design to Marines without at least bouncing it off of an 0650.  Additionally, your design should be influenced by expected future expansion.  Everything down to how you address your endpoints will be influenced by these expectations.  It comes down to a choice: flexibility and scalability will in most cases increase complexity, where designing for the here and now will be the path of least resistance, at least in the short term.  Some good planning considerations put forth by Cisco is to stick to 20:1 for access to distribution, and 4:1 from distribution to core.  Example: You are using 36 ports in a 48 port switch.  If you are using all gigibit ports, this access switch should have two uplink ports.

Implement

Remember the troop leading steps – BAMCIS?  Here is a to scale drawing:

This is already a really long post, so I am not going to get into the explanation of BAMCIS (you can look here for a quick explanation).  Make sure you are supervising this step. It is going to sound crazy, but it is amazing the number of times I have found the executors were never given the plan. You can easily tell how things are going by checking to see if the Marines configuring the gear have diagrams. If they don’t have diagrams, ask them where they got the info they are using (IP addresses, frequencies, etc). The same guidance goes for camp setup, power grid, etc. There are always going to be changes, so you won’t be forcing everyone to stick to the plan, but you will need to make sure that any last minutes changes are accurately logged and diagrams updated accordingly. If the changes during this stage affect capabilities, be sure to notify the appropriate personnel (whoever it affects and your boss).

Operate

The operate stage consists of using the assets you have employed. It is important to compare your advertised/expected performance to the actual performance. The challenge here is two-fold. First, users generally do not like to complain (to you) unprompted. This is where is it important for you to walk around and continually check up on the status of your assets. It will seem repetitive, but go around asking the users if their assets are working up to their expectations. Anything noted as deficient needs to be validated, and possibly worked on during the next stage. The second challenge is one of low expectations. We are routinely presented with incredibly difficult situations for which the gear and underlying protocols were not designed, and this is well understood by both the communicators and the users. Many shortfalls are erroneously attributed to these low expectations, and problems are either written off, or incorrect root causes assigned.  More than any time, it is important to stay focused and validate assumptions.  If you have a Marine that is savvy with Wireshark, this is the preferred tool because the packets never lie.  You should also continue the work mainly completed in the last stage, validating and updating your diagrams.  Diagram updates are something I consider network hygiene, a task which must be continually performed and never completed.

Optimize

The sixth and final stage, optimize, takes the network you are operating and squeezes the best performance out.  Given we are almost always going to be operating in a bandwidth constrained environment, understand that changes made to “enhance” one protocol/application will affect the performance of all of the other traffic.  If you end up doing something that is particularly beneficial during this stage, document the changes and the reason for the changes and share this with the community.  It is fairly rare to have big wins in this stage, and it is absolutely painful having to watch units continually struggle with the same issues.  This is the principle reason why I started this blog.

I hope this writeup gives you a starting point for a format to use for your comm planning.  As always, I’m interested in any feedback you have or any recommended changes to anything I have written.